Microservices

Microservices

Design and operate microservice architectures.

Service Boundaries

Bounded Context (DDD)

• Each service owns a domain concept
• Service has its own database (no DB sharing)
• Communication via API or events
• Avoid "shared" services (leads to tight coupling)

Service Sizing

• Too small: Nano-services — high overhead, hard to debug
• Too large: Distributed monolith — worst of both worlds
• Right size: Team can build, test, deploy independently

Communication Patterns

| Pattern | Type | When |

|---------|------|------|

| REST | Sync | Request-response, CRUD |

| gRPC | Sync (fast) | Internal, high throughput |

| Event | Async | Decoupled workflows |

| Message Queue | Async | Buffered, reliable delivery |

Event-Driven Communication

Service A → Event Bus → Service B
                       → Service C
                       → Service D

Benefits: eventual consistency, loose coupling, replayability.

CQRS (Command Query Responsibility Segregation)

• Separate read and write models
• Queries go to optimized read stores (materialized views)
• Commands go to write stores (normalized)
• Eventually consistent between them

Distributed Tracing

• Correlation ID passed across all services
• Use OpenTelemetry for instrumentation
• Trace each request: Service → Queue → DB → External API
• Visualize in Jaeger or Zipkin
• Alert on traces that exceed latency SLOs

Anti-Patterns to Avoid

❌ Shared database between services

❌ Sync chains (A → B → C → D blocking)

❌ Distributed monolith (microservices but deployed together)

❌ Absent monitoring ("it works in dev")

❌ Premature decomposition (start monolith, extract carefully)