microservices-architecture

Microservices Architecture Skill

This skill complements (does not replace) the microservices.md fragment. Load the fragment for general principles; use this skill for design decisions.

Step 1 — Service Boundary Analysis

Use Domain-Driven Design bounded contexts to identify service boundaries:

1. List the core business domains (e.g., Orders, Inventory, Payments, Notifications).
2. For each domain, identify:
   • The aggregate root (the entity other entities reference through).
   • The invariants that must hold within the domain.
   • The external events the domain publishes when its state changes.
3. A service boundary aligns with a bounded context. Services should not share a database.

Red flags for a bad boundary:

• Two services always change together → consider merging them.
• A service has no domain logic (only CRUD) → it may not need to be a separate service.
• A service synchronously calls another service on every request → tight coupling.

Step 2 — Communication Pattern Decision

For each service-to-service interaction, choose:

Scenario	Pattern	Trade-off
Read-your-own-writes, low latency	Synchronous REST/gRPC	Temporal coupling; caller waits
Background processing, at-least-once	Async messaging (SQS, RabbitMQ)	Eventual consistency; harder to debug
Event fan-out (multiple consumers)	Pub/sub (EventBridge, Kafka)	Loose coupling; no direct contract
Streaming / time-series data	Kafka / Kinesis	High throughput; complex ops

Rule: prefer async messaging for writes across service boundaries. Use sync calls only for reads where the caller genuinely needs the response before proceeding.

Step 3 — Data Consistency Design

You cannot have distributed transactions without accepting trade-offs. Choose:

Saga (choreography or orchestration):

• Each service publishes an event after its local transaction commits.
• On failure, compensating transactions undo previous steps.
• Use the outbox pattern to guarantee event publication.