gabrielmoreira 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)