Domande Architettura — Cheat Sheet
Tags: architecture, system-design, microservices, scalability, patterns
Level: advanced
TL;DR: Quick reference for software architecture interview questions, covering distributed systems, scalability patterns, CAP theorem, and common architectural trade-offs.
Key concepts
CAP Theorem states a distributed data store can guarantee only two of three: Consistency, Availability, Partition tolerance.
Horizontal scaling adds more machines to the pool; vertical scaling adds power (CPU, RAM) to an existing machine.
Microservices decouple a system into independent, deployable services organized around business capabilities.
Eventual consistency ensures that given enough time, all updates will propagate through the system and replicas will converge.
CQRS (Command Query Responsibility Segregation) separates read models from write models to optimize for different workloads.
API Gateway acts as a reverse proxy to accept all API calls, aggregate services, and handle cross-cutting concerns like auth.
Message queues decouple producers and consumers, smoothing out traffic spikes and enabling asynchronous processing.
Typical questions and ready answers
Q: How do you choose between microservices and a monolith?
R: I start with a modular monolith for speed and simplicity. I extract microservices only when specific domains require independent scaling, separate deployment lifecycles, or completely different technology stacks.
Q: Explain how you would apply the CAP theorem in a real-world scenario.
R: Since network partitions are inevitable, I must choose between Consistency and Availability. For a financial ledger, I choose Consistency. For a social media feed, I choose Availability and rely on eventual consistency.
Q: How do you handle distributed transactions across microservices?
R: I avoid distributed transactions (2PC) due to locking issues. Instead, I implement the Saga pattern using asynchronous events to trigger compensating transactions if a step fails.
Q: How would you improve the performance of a read-heavy system?
R: I introduce caching layers using Redis or Memcached before the database. If the database remains a bottleneck, I implement read replicas to distribute the query load.
Pitfalls and common mistakes
Premature optimization by designing complex distributed systems before the actual traffic scale requires it.
Ignoring the Fallacies of Distributed Computing, specifically assuming network latency is zero and network is reliable.
Creating a "distributed monolith" where microservices are so tightly coupled they must be deployed simultaneously.
Using synchronous API calls between microservices instead of asynchronous events, leading to cascading failures.
To review
[ ] Saga pattern choreography vs orchestration trade-offs.
[ ] Fallacies of Distributed Computing checklist.
[ ] Sharding strategies and consistent hashing algorithms.
Modifica direttamente o con Gemini Fai clic in un punto qualsiasi per digitare e modificare direttamente oppure seleziona il testo per chiedere a Gemini di apportare modifiche.
The cheat sheet has been updated with detailed architectural concepts, targeted interview questions, and common pitfalls to watch out for during technical discussions.
