🧩 Service Decomposition & Microservices

Know when to split a monolith, how to draw service boundaries, and how to manage the complexity that follows.

Microservices are not a starting point — they are an outcome. I have seen too many teams adopt a distributed architecture before they understood their domain well enough to draw stable boundaries. The result is a distributed monolith: all the operational complexity of microservices with none of the independence. My default recommendation for early-stage products is to start with a well-structured monolith, understand the domain thoroughly, and extract services only when a clear scaling or team autonomy need arises.

When decomposition is warranted, I use Domain-Driven Design (DDD) concepts to guide boundary decisions. A bounded context defines the scope within which a particular domain model applies. Services should align with bounded contexts — not with technical layers (e.g., "the database service") or arbitrary size targets. A good service owns its data, exposes a stable interface, and can be deployed independently of its neighbors. If two services must always be deployed together, they are probably one service.

Service communication patterns matter as much as the boundaries themselves. I prefer asynchronous, event-driven communication between services wherever latency requirements allow — it reduces temporal coupling and makes each service more resilient to failures in others. Where synchronous calls are necessary, I apply patterns like circuit breakers, retries with exponential backoff, and timeouts to prevent cascading failures. Every inter-service call is a potential failure point; designing for failure is not optional in a distributed system.

Operational maturity must keep pace with service count. Each new service adds CI/CD pipelines, observability configuration, infrastructure provisioning, and on-call responsibility. I treat these as real costs, not paperwork, and ensure the team has the platform tooling — container orchestration, service discovery, centralized logging — before it is needed. The goal of service decomposition is autonomous teams shipping independently and reliably; without the operational foundation, it becomes a source of friction rather than speed.