Microservices decompose an application into small, independently deployable services that communicate over well-defined APIs (REST, gRPC, or message queues).
Architecture
┌──────────┐ ┌──────────┐ ┌──────────┐
│ User Svc │ │ Order Svc│ │ Pay Svc │
│ ┌────┐ │ │ ┌────┐ │ │ ┌────┐ │
│ │DB │ │ │ │DB │ │ │ │DB │ │
│ └────┘ │ │ └────┘ │ │ └────┘ │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└───────────────┼───────────────┘
│
┌──────┴──────┐
│ API Gateway │
└──────┬──────┘
│
Clients
When to Use
- Multiple teams that need independent deploy cadences
- Independent scaling — one service needs 10x the resources of others
- Fault isolation — one service crash doesn’t take down everything
- Technology diversity — different services can use different languages
When to Avoid
- Small team — operational overhead is too high
- Simple domain — CRUD doesn’t need distributed complexity
- Tight consistency requirements — distributed transactions are hard
Key Decisions
| Decision | Options | Trade-off |
|---|---|---|
| Communication | REST, gRPC, messaging | Sync vs. async coupling |
| Data | Shared DB, DB per service | Consistency vs. autonomy |
| Discovery | DNS, service mesh, registry | Simplicity vs. observability |
| Deployment | Containers, serverless | Control vs. convenience |
Challenges
- Distributed data — no ACID across services; plan for eventual consistency
- Network failures — design for retries, circuit breakers, timeouts
- Observability — distributed tracing is essential (OpenTelemetry, Jaeger)
- Testing — contract tests replace integration tests across service boundaries