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 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 Design a System for 1 Million Requests per Second
A step-by-step system design for 1M requests/sec — capacity math with Little's Law, edge caching, load balancing, multi-level caching, consistent-hash sharding, async queues, rate limiting, circuit breakers and autoscaling, with Java examples and the mistakes most designs make.
Kafka for Backend Engineers: Partitions, Ordering and Delivery Guarantees
How Kafka topics, partitions and consumer groups actually work, why ordering is only per partition, and what at-least-once and exactly-once really mean for your Spring Boot services.
Designing a Rate Limiter: Token Bucket, Sliding Window and Redis
The algorithms behind API rate limiting, their trade-offs, and how to build a distributed limiter with an atomic Redis Lua script — a classic system design interview question, solved end to end.
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?