Microservices patterns describe common ways to design, connect, protect, and monitor independently deployable services. This cheat sheet helps students recognize when each pattern is useful and what tradeoffs it introduces. It is especially helpful when comparing distributed system designs, cloud architectures, and enterprise application patterns.
The focus is on practical reference rules rather than implementation details for a single programming language.
The core ideas include splitting systems around business capabilities, routing requests through gateways, and keeping services discoverable as instances change. Reliability patterns such as circuit breakers, retries, bulkheads, and timeouts help prevent cascading failures. Data patterns such as sagas, CQRS, and event sourcing handle consistency when no single database owns every transaction.
Observability patterns use logs, metrics, traces, and correlation IDs to make distributed behavior understandable.
Key Facts
- Decompose by business capability: each service should own one cohesive business function and its data.
- API Gateway rule: client request -> gateway -> one or more backend services, with routing, authentication, and aggregation handled at the edge.
- Service discovery rule: service instance registers location -> registry stores it -> client or gateway resolves a healthy instance before calling.
- Circuit breaker states are closed, open, and half-open, and calls are blocked when repeated failures move the breaker to open.
- Retry rule: retry only transient failures, use exponential backoff such as delay = baseDelay * 2^attempt, and avoid retrying non-idempotent operations without safeguards.
- Saga pattern rule: long business transaction = sequence of local transactions plus compensating actions for rollback-like behavior.
- CQRS separates command models that change state from query models that read state, often using different schemas or stores.
- Observability rule: every request should carry a correlation ID so logs, metrics, and traces can be connected across services.
Vocabulary
- Microservice
- A small, independently deployable service that owns a specific business capability and usually manages its own data.
- API Gateway
- A service entry point that routes client requests, applies cross-cutting policies, and may combine responses from multiple services.
- Circuit Breaker
- A reliability pattern that stops calls to a failing dependency after a threshold is reached so the system can recover.
- Saga
- A distributed transaction pattern that coordinates multiple local transactions using events or commands and compensating actions.
- CQRS
- Command Query Responsibility Segregation is a pattern that separates write operations from read operations.
- Event Sourcing
- A persistence pattern where state is stored as a sequence of events rather than only as the latest current value.
Common Mistakes to Avoid
- Splitting services by technical layer, such as controller, service, and database, is wrong because it creates distributed versions of a monolith instead of business-aligned services.
- Sharing one database across many microservices is wrong because it couples deployments, hides ownership, and makes schema changes risky.
- Retrying every failed request immediately is wrong because it can amplify outages and overload a dependency that is already unhealthy.
- Using sagas as if they provide traditional ACID rollback is wrong because sagas rely on local transactions and compensating actions, so intermediate states may be visible.
- Skipping observability until production is wrong because distributed failures are hard to diagnose without structured logs, metrics, traces, and correlation IDs.
Practice Questions
- 1 A payment service fails 5 times in a row, and the circuit breaker threshold is 3 failures. What state should the circuit breaker enter after the third failure?
- 2 A retry policy uses delay = 100 ms * 2^attempt, starting with attempt = 0. What delays are used for attempts 0, 1, 2, and 3?
- 3 An order workflow reserves inventory, charges a card, and schedules shipping across three services. Which pattern is best for coordinating this workflow without a single distributed database transaction?
- 4 Explain why a team might choose CQRS for a high-traffic product catalog, and describe one tradeoff that comes with that choice.