Core Patterns at a Glance
Microservices architecture rests on a handful of recurring patterns: each service owns its own database (database-per-service), an API gateway fronts external traffic and routes to internal services, service discovery lets services find each other's network locations dynamically, and the Saga pattern coordinates data consistency across services without distributed transactions. Knowing these five by name and by the specific problem each solves is the fastest way to sound fluent in a design discussion.
Cricket analogy: Database-per-service is like each franchise in a league owning its own training facility rather than sharing one national academy, so a change to one team's fitness program doesn't disrupt another's schedule.
Communication Styles Cheat Sheet
Synchronous communication (REST or gRPC over HTTP) is simple to reason about but couples the caller's availability to the callee's uptime and latency; use it when the caller genuinely needs an immediate answer, like validating a payment before confirming an order. Asynchronous communication (message queues like RabbitMQ or event streams like Kafka) decouples services in time, letting the publisher continue even if a consumer is temporarily down, and is the right default for anything that doesn't need an immediate response, like sending a confirmation email after checkout.
Cricket analogy: A synchronous call is like a batter waiting at the crease for the third umpire's live decision before continuing; an asynchronous call is like the ground staff logging pitch conditions to a report that groundskeepers review later without blocking play.
# Quick-reference resilience config (Kubernetes + Istio style)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: inventory-service
spec:
host: inventory-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 50 # bulkhead: cap resource usage per dependency
outlierDetection:
consecutive5xxErrors: 5 # circuit breaker: trip after 5 failures
interval: 10s
baseEjectionTime: 30s
tls:
mode: ISTIO_MUTUALResilience Pattern Cheat Sheet
Circuit breakers stop calling a dependency that's already failing, giving it time to recover and preventing wasted resources on doomed requests; retries with exponential backoff and jitter handle transient failures without hammering a struggling service in lockstep; bulkheads isolate resource pools (threads, connections) per dependency so one slow dependency can't starve unrelated calls; and timeouts prevent any single call from hanging indefinitely and tying up caller resources.
Cricket analogy: A circuit breaker is like a captain resting an out-of-form bowler after conceding runs in three straight overs rather than persisting and letting the damage compound further.
Quick decision rule: if the caller cannot proceed without the response, use synchronous communication with a strict timeout and circuit breaker; if the caller can proceed and the effect can happen 'eventually,' use asynchronous messaging.
Don't stack unbounded retries on top of a synchronous call chain without backoff and a circuit breaker; naive retries at every hop in a multi-service chain can multiply load exponentially during an incident and turn a partial outage into a full one (a retry storm).
- Five core patterns: database-per-service, API gateway, service discovery, Saga, and event-driven messaging.
- Use synchronous calls when the caller needs an immediate answer; async otherwise.
- Circuit breakers stop calling a failing dependency to let it recover.
- Retries need exponential backoff and jitter to avoid synchronized hammering.
- Bulkheads isolate resource pools per dependency so one slow dependency can't starve others.
- Timeouts cap how long any single call can hang, protecting caller resources.
- Watch for retry storms: unbounded retries without backoff can turn a partial outage into a full one.
Practice what you learned
1. Which pattern lets each service own and manage its own database independently?
2. What is the primary risk of unbounded retries without backoff in a service chain?
3. When should you prefer asynchronous communication over synchronous?
4. What does a bulkhead pattern protect against?
5. What real-world system uses a mechanism literally called a 'circuit breaker' that mirrors the software pattern?
Was this page helpful?
You May Also Like
Microservices Interview Questions
The core system-design and conceptual questions interviewers use to probe real microservices experience, with the reasoning behind strong answers.
Observability in Microservices
How to understand the internal state of a distributed system from the logs, metrics, and traces it produces, so you can debug failures you never anticipated.
Distributed Tracing Explained
How spans, trace context propagation, and tools like Jaeger or OpenTelemetry let you follow a single request as it crosses dozens of microservices.
Testing Microservices
How the test pyramid, contract testing, and chaos experiments combine to give confidence in a system made of many independently deployed services.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics