service-decompositionlisted

# Service Decomposition Decide how to carve a system into deployable services — or whether to — and how those services find and call each other. This is the "application layer" of a design: it sits between the edge (`dns`/`load-balancing`/`content-delivery`) and the data tier. Getting the *granularity* wrong is one of the most expensive mistakes in distributed systems, in both directions. > The trap cuts both ways. One giant service can't scale teams or components > independently; a swarm of tiny ones drowns you in network hops, partial > failures, and undebuggable cross-service traces. The skill is finding the > sweet spot for *this* system at *this* size — not maximizing service count. ## When to reach for this A second service is on the table; teams need to deploy independently; one part has a wildly different scaling profile than the rest; or an existing system is "too chatty" / hard to change. Also when someone proposes "microservices" by default. ## When NOT to A new product / small team / unproven domain — start with a **monolith** (or a modular monolith) and split later when a real seam and a real reason appear. Splitting prematurely buys distributed-systems cost (network failure, eventual consistency, ops) to solve a problem you don't have yet (YAGNI, GUIDE #7). Don't add a gateway/mesh/discovery layer before you have services that need them. ## Clarify first - **Team & deploy independence** — must parts ship on separate cadences/owners? - **Differential scale**