Microservices Patterns
Design microservices correctly - service boundaries, saga pattern for distributed transactions, API gateway, circuit breakers, and the dark side of microservices.
skill: Microservices Patterns category: Backend tags: [Microservices, Service Design, Saga Pattern, API Gateway, Circuit Breaker] readingTime: 7
Microservices solve organizational coupling, not technical problems. If you don't have independent teams deploying at different cadences, a monolith is simpler and faster. Microservices introduce distributed system problems (network partitions, partial failures, data consistency) - know these patterns before you need them.
Workflow
- Define service boundaries with DDDService boundaries drawn around technical layers (all databases in one service) create chatty, tightly coupled microservices. DDD Bounded Contexts align service boundaries with business domains.
- Implement saga for distributed transactionsYou can't use a SQL transaction across two microservices. The Saga pattern coordinates multi-service operations with compensating transactions on failure.
- Implement circuit breakersWhen a downstream service is slow or failing, your service piles up requests waiting for timeouts - cascading failure. A circuit breaker trips after N failures and fast-fails immediately.
- Design the API gatewayAn API gateway is the single entry point for all clients - it handles auth, rate limiting, routing, and protocol translation without each microservice implementing these cross-cutting concerns.
- Handle service discovery and health checksIn a dynamic container environment, services move between hosts and change IP addresses. Service discovery enables services to find each other without hardcoded addresses.
Output Format
Microservices: DDD-aligned bounded context boundaries, choreography saga with compensating transactions, opossum circuit breaker with fallback, API gateway with BFF, and liveness/readiness health endpoints.
Service boundaries: one bounded context per service
Saga: event chain (OrderCreated → PaymentSucceeded → ItemsReserved)
Circuit breaker: opossum { timeout, errorThresholdPercentage, resetTimeout }
Gateway: authenticate + rateLimit + proxy per service
Health: /health/live (process) + /health/ready (dependencies)Examples
Edge Cases & Gotchas
- Saga rollback ordering - Compensating transactions must be idempotent (safe to run multiple times) and must run in reverse order. If InventoryReservationFailed, must undo PaymentCharged before undoing OrderCreated.
- Choreography vs. orchestration - Choreography (event-driven) is decoupled but hard to trace. Orchestration (workflow engine like Temporal) is easier to debug but adds a coordinator. Choose based on complexity.
- Service mesh vs. sidecar for circuit breaking - Istio/Envoy can implement circuit breaking at the network layer without application code. Application-level circuit breakers (opossum) give more control over fallback behavior.
- API gateway as a bottleneck - A single API gateway is a single point of failure and a performance bottleneck. Deploy multiple gateway replicas behind a load balancer and avoid stateful gateway design.
When to Break These Rules
- Use a monolith until you have independent teams with genuinely different deployment cadences - microservices are an organizational solution, not a technical one.
- Use orchestration saga (Temporal, AWS Step Functions) instead of choreography saga for complex workflows with many steps - choreography becomes unreadable at 6+ services.
Reference Files
https://microservices.io/patterns/https://temporal.io/docs