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)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: cosmicstack-labs
• Source: cosmicstack-labs/mercury-agent-skills
• License: MIT
• Homepage: https://skills.mercuryagent.sh

Install and usage instructions live in the source repository linked above.