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)