Microservices Patterns Every Senior Engineer Should Know
Saga, circuit breaker, API gateway, event sourcing — the design patterns that make microservices work at scale and that interviewers ask about.
Microservices Patterns Every Senior Engineer Should Know
Microservices solve the deployment and scaling problems of monoliths — and introduce a dozen new ones. These patterns are how you solve them.
1. API Gateway
A single entry point for all clients. Handles routing, auth, rate limiting, and response aggregation.
Client → API Gateway → User Service
→ Order Service
→ Payment Service
The gateway calls multiple services and merges responses, so clients don't need to know the internal topology.
2. Circuit Breaker
When a downstream service is failing, don't keep hammering it — open the circuit and fail fast.
States: CLOSED (normal) → OPEN (failing fast) → HALF-OPEN (testing recovery)
Java: Use Resilience4j's @CircuitBreaker annotation with Spring Boot.
3. Saga Pattern (Distributed Transactions)
Across microservices, you can't have ACID transactions. Use sagas — a sequence of local transactions with compensating transactions on failure.
Choreography Saga: Services emit events and react to each other. No central orchestrator. Harder to debug.
Orchestration Saga: A central orchestrator tells each service what to do. Easier to trace but adds coupling.
4. Event Sourcing
Instead of storing the current state, store the sequence of events that led to the current state.
CartCreated → ItemAdded → ItemAdded → ItemRemoved → OrderPlaced
Current state is derived by replaying events. Gives you full audit trail and temporal queries.
5. CQRS (Command Query Responsibility Segregation)
Separate the read model from the write model. The write side stores normalised data. The read side maintains pre-computed, denormalised views optimised for queries.
Common combo: Event Sourcing + CQRS. Write events to an event store. Project them into read models (Elasticsearch, materialized views).
Related Posts
How to Crack the System Design Interview
Most engineers fail system design interviews not because they lack knowledge, but because they lack a framework. Here's the repeatable 6-step approach that works.
CAP Theorem: What It Actually Means for System Design
CAP theorem says you can only pick 2 of 3 properties. But what does that mean in practice? And which systems are CP vs AP vs CA?