How do cohesion and coupling act as opposing forces when you're deciding how large or small to make a microservice, and what heuristics help you find the right boundary?

## The two forces, defined - **Cohesion** measures how strongly the responsibilities gathered inside one module — here, one microservice — belong together, typically judged by whether they change for the same reasons and are used together. - **Coupling** measures how much one module depends on another's internal details, and in a distributed system this includes not just code dependencies but shared data, shared release timing, and shared runtime availability. The classic software-design heuristic, going back to structured design and restated for OO/SOLID design, is: maximize cohesion within a module, minimize coupling between modules. Applied to service sizing, this means the 'right' service boundary is the one where everything inside genuinely belongs together (high cohesion) and where interactions with other services are as few, as coarse-grained, and as stable as possible (low coupling). ## Why every split adds coupling Splitting a service always adds some coupling, because whatever used to be an in-process function call between the split pieces now becomes a network call with a versioned contract, and the two new services must agree on data ownership, release compatibility, and failure handling. Whether the split is worth that coupling cost depends entirely on cohesion: - **If the two halves genuinely didn't belong together** — they changed for different reasons, were owned by different teams, needed to scale differently — then splitting removes an accidental coupling that existed only because they were bundled, and the net effect is positive. - **But if the two halves actually did belong together** (e.g., they're two steps of one workflow that almost always change in the same commit), splitting them doesn't remove real coupling, it just relocates it from 'compile-time, in-process' to 'runtime, over-the-network' — strictly worse, since network coupling is harder to change atomically and fails independently. This is the core intuition behind why 'smaller is not automatically better': every split is a bet that the cohesion gained outweighs the network coupling introduced. ## Concrete tests for the boundary Several concrete tests help locate the right boundary. 1. **The common-closure principle** asks: do these things tend to change in the same commit/PR? If yes, they're cohesive and belong together. 2. **The transactional-boundary test** asks: does this operation need strong, immediate consistency across these pieces of data (e.g., debiting one account and crediting another must both succeed or both fail)? If yes, keeping them in one service lets you use a local ACID transaction instead of building a saga; if the consistency requirement is genuinely eventual, splitting is safer. 3. **The bounded-context test**, from Domain-Driven Design, asks whether two areas use the same business vocabulary with the same meaning — if 'Customer' means something different to Billing than it does to Support, that's a signal they're separate bounded contexts even though they share a name. 4. **Team-ownership alignment** (deliberately shaping architecture to match desired team structure, sometimes called an 'inverse Conway maneuver') is also a heuristic: a boundary that lets one small team own a service end-to-end, without needing sign-off from another team to ship a change, is usually closer to correct than one that requires cross-team coordination for routine changes. ## Getting it wrong in either direction Getting this wrong in either direction has recognizable symptoms, and here is how each shows up. | Failure mode | Symptoms | |---|---| | Too little cohesion inside a service (grab-bag responsibilities bundled for convenience) | a service touched by many unrelated feature teams, frequent merge conflicts, and surprising blast radius because unrelated features share deploy risk | | Too much coupling between services | chatty-communication smells, cascading failures, and 'distributed monolith' symptoms — needing to deploy several services together in a specific order to ship one feature, which erases the independent-deployability benefit microservices are supposed to provide | Both failure modes are visible in code review and incident retros — watch for: - pull requests that routinely touch two or three services together (a coupling smell suggesting they should merge) - services whose changelog reads like an unrelated grab-bag of features (a cohesion smell suggesting they should split) ## The trade you make at each boundary A widely cited real scenario is Amazon's early-2000s 'two-pizza team' reorganization, credited by various retrospective practitioner accounts with pushing services toward boundaries owned end-to-end by small teams, explicitly trading some duplication of code and data across services for drastically reduced cross-team coordination — accepting slightly lower 'DRY-ness' (a coupling reduction) in exchange for team-level autonomy (a cohesion/ownership win). The lesson generalizes: cohesion and coupling aren't absolute values to be globally minimized/maximized independently, they're a trade you make deliberately at each boundary, and the right granularity is the one where you've consciously chosen which coupling you're willing to accept in exchange for which cohesion you're buying.