microservices

# Microservices ## Purpose Decide where service boundaries belong — and whether you need them at all. Splitting a system converts function calls into network calls, and every network call is a new failure mode you must design for. ## When to Use - Considering extracting a service from a monolith. - Defining boundaries for a system that will be built as services. - Diagnosing a distributed system that has become a "distributed monolith". - Designing a transaction that spans services. ## Capabilities - Boundary identification along business capabilities and data ownership. - Communication design: synchronous versus asynchronous, and when each is correct. - Distributed data: the outbox pattern, sagas, eventual consistency. - Resilience: timeouts, retries with backoff, circuit breakers, bulkheads. - Observability: correlation IDs and distributed tracing. ## Inputs - The current system and the concrete problem services are meant to solve. - Team topology — services follow team boundaries whether you intend them to or not. - Consistency requirements per operation. ## Outputs - Service boundaries with owned data and a published contract. - A communication pattern per interaction, chosen deliberately. - Failure behavior for each cross-service call. ## Workflow 1. **Justify the split** — The valid reasons are independent deployability, independent scaling, and team autonomy. "Microservices are best practice" is not a reason. 2. **Draw boundaries around data** — A service o...