Designing Microservices Architecture
1. Decomposing Monoliths into Microservices
| Step | Action |
|---|---|
| Identify seams | Bounded contexts, cohesive modules |
| Extract module | Modular monolith first |
| DB extraction | Schema split, then physical DB |
| Strangler facade | Route traffic to new service |
| Decommission legacy | Remove old code paths |
2. Designing Service Discovery
| Mechanism | Tool |
|---|---|
| Client-side | Eureka, Consul |
| Server-side (LB) | K8s Service, AWS ALB |
| DNS-based | K8s CoreDNS, Route53 |
| Service mesh | Istio, Linkerd, Consul Connect |
3. Designing API Gateway Pattern
| Function | Tool |
|---|---|
| Single entry | Kong, Envoy, Apigee, AWS API GW |
| AuthN/Z | JWT, OIDC at edge |
| Aggregation | BFF pattern |
| Observability | Centralized metrics + traces |
4. Designing Inter-Service Communication
| Pattern | Use Case |
|---|---|
| Sync HTTP/REST | Simple, debug-friendly |
| Sync gRPC | Low-latency, typed |
| Async events (Kafka, NATS) | Decoupled, resilient |
| Async commands (RabbitMQ, SQS) | Work queues |
| Choreography vs orchestration | Distributed control vs central |
5. Designing Service Mesh
| Capability | Description |
|---|---|
| mTLS | Auto-issued cert per pod |
| Traffic shifting | Canary, mirror, fault injection |
| Retries / timeouts | Declarative per route |
| Observability | L7 metrics + tracing automatic |
| Tools | Istio, Linkerd, Consul, Kuma, Cilium |
6. Designing Distributed Tracing Architecture
| Component | Detail |
|---|---|
| Spec | OpenTelemetry, W3C traceparent |
| Collector | OTel Collector → backend |
| Backend | Jaeger, Tempo, Honeycomb, Datadog |
| Sampling | Head-based or tail-based (1–10%) |
| Trace ID propagation | Through all hops + queues |
7. Designing Circuit Breaker Pattern
Closed ──fail rate > threshold──▶ Open
▲ │
│ success │ wait timeout
│ ▼
Half-Open ◀──── probe call ────── Open
| State | Behavior |
|---|---|
| Closed | All calls pass; track failures |
| Open | Fail fast; no calls reach service |
| Half-Open | Allow few probes; close on success |
| Library | Resilience4j, Polly, Hystrix (legacy) |
8. Designing Service Versioning Strategy
| Approach | Detail |
|---|---|
| SemVer | Major.Minor.Patch |
| Side-by-side deploy | v1 and v2 both running |
| Header routing | X-Service-Version |
| Contract tests | Pact between consumers and producer |
9. Designing Saga Pattern for Distributed Transactions
| Type | Coordination |
|---|---|
| Choreography | Services react to events |
| Orchestration | Central orchestrator (Temporal, Camunda) |
| Compensation | Inverse step on failure |
| Idempotency | Required for retries |
10. Designing Bounded Contexts
| Service Boundary Heuristic | Detail |
|---|---|
| Single team owns | 2-pizza team |
| Independent deploy | Daily cadence |
| Owns its data | No shared DB |
| Cohesive domain | One ubiquitous language |
11. Designing Microservices Data Management
| Pattern | Detail |
|---|---|
| DB per service | No shared DBs |
| Event-carried state transfer | Replicate needed data via events |
| CQRS | Read model in consumer service |
| Outbox pattern | Atomic state + event publish |
| Saga | Cross-service workflows |
12. Designing Microservices Testing Strategy
| Layer | Test |
|---|---|
| Unit | Domain logic, fast |
| Integration | Service + DB (Testcontainers) |
| Contract | Pact, consumer-driven |
| Component | Service isolated, deps mocked |
| End-to-end | Few critical journeys |
| Chaos | Failure injection in staging/prod |