Cohesion in Practice

Cohesion is the other half of the coupling question and the more often neglected one. Low coupling is easy to fake by splitting things finely; you then discover that a single feature touches nine services, which is a cohesion failure, not a coupling success.

The operational test is change correlation: look at the last fifty commits or the last twenty features. Which components changed together? Things that consistently change together belong in the same boundary regardless of what the taxonomy says.

Industry example

Spotify's organisational model — small autonomous squads owning a slice end to end — is routinely copied for its team structure and rarely for the property that makes it work: the boundaries were drawn around things that change together. A squad owning "playlist" owns the storage, the service, and the client surface, so a playlist change is one team's decision.

Where copies fail is when boundaries are drawn along technology layers instead — a frontend team, a backend team, a database team. Coupling between those units looks low on the diagram and is catastrophic in practice, because every user-visible change requires all three to coordinate. Conway's Law then locks the mistake in: the architecture and the org chart reinforce each other.

Spotify's own engineers have pointed out that the published model was never fully true internally and should not be adopted as a blueprint. That is part of the lesson: the useful artefact was the principle about change correlation, not the org chart.

Failure scenarios

• Entity services. A "Customer Service", an "Order Service" and a "Product Service" that must all be modified for any real feature. High cohesion by noun, none by change.
• Utility sprawl. A shared "common" module that everything depends on and nothing owns.
• Layer teams. Boundaries drawn on technology, so every feature is a three-team negotiation.

Trade-off

High cohesion sometimes means a bigger component than fashion prefers. A module that owns rather more than feels tidy, but can be changed by one team without coordination, is the better engineering outcome than four elegant modules that always ship together.

Interview question

"How would you use commit history to decide whether an existing service boundary is in the wrong place?"