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)

Microservices