Microservices Design Patterns
Decomposition, integration, data, resilience and deployment patterns for service-based systems.
Microservices trade the simplicity of one deployable for independent teams and scaling. Each trade brings a new problem, and each problem has a well-known pattern.
Think of the patterns in groups: how to split services, how they communicate, how they own data, how they survive failure, and how they are deployed and observed.
Diagram
Key concepts
- Decompose by business capability
- Each service owns one bounded context (Orders, Inventory) with its own language and rules.
- Database per service
- No shared tables. Other services get data through APIs or events.
- API gateway & BFF
- One entry point for clients, optionally one per client type.
- CQRS
- Separate write models from read models; reads can come from a denormalised projection.
- Saga
- Manage a business transaction across services with local transactions and compensations.
- Strangler fig
- Migrate a monolith gradually by routing feature after feature to new services.
- Service discovery & mesh
- Find service instances dynamically; a mesh (Istio, Linkerd) adds mTLS, retries and telemetry.
- Sidecar
- A helper container beside each service for proxying, logging or configuration.
Trade-offs
Benefits
- Teams deploy independently and choose fitting tech
- Scale only the services that need it
- Failures can be isolated
Costs
- Network latency and partial failures everywhere
- Distributed data and eventual consistency
- Much higher operational and observability needs
Use it when
- Several teams working on one product
- Parts of the system with very different scaling or release needs
Common mistakes
- Shared database between services
- Long chains of synchronous calls (A → B → C → D)
- Too many tiny services (“nanoservices”) for a small team
- No distributed tracing
Interview questions
Q1How do you query data that spans two services?
Call both APIs and compose (API composition), or keep a read model updated from both services’ events (CQRS projection). Don’t join across their databases.
Q2What is the strangler fig pattern?
Place a proxy in front of the monolith, then build new features or rewrite old ones as services and route those paths to them until the monolith can be retired.
Q3What does a service mesh give you?
Mutual TLS, retries, timeouts, traffic shifting and telemetry between services, implemented in sidecar proxies instead of every codebase.
Related lessons
Messaging & Microservices
The Saga Pattern
Run a business transaction across services as a series of local steps with compensations.
Messaging & MicroservicesResilience: Timeouts, Retries & Circuit Breakers
Contain failures so one slow dependency doesn’t take the whole system down.
FoundationsArchitecture Styles
Monolith, modular monolith, microservices, event-driven and serverless — and how to choose.