Every meaningful feature in a platform requires changes to at least nine services and three teams. Which architectural property has failed and what is the diagnostic?

What is being tested

Whether you can distinguish a cohesion failure from a coupling failure. They present similarly and have opposite fixes.

The reasoning

Coupling is about runtime dependency: how much A must know about B, and whether A can work when B is down. Cohesion is about change: whether the things inside a boundary belong together.

"Every feature touches nine services" is a statement about change, not about runtime. It can be true even in a system with beautifully decoupled runtime interactions. The functionality that a user perceives as one thing has been scattered across nine boundaries, so the boundaries do not correspond to anything real.

The trap is that the obvious response — "reduce coupling" — makes it worse. Splitting further, or adding indirection between the nine, increases the number of places a change must land.

The diagnostic

Change correlation from version control. Take the last fifty merged pull requests or the last twenty delivered features. For each, list the repositories or modules touched. Build the co-occurrence matrix. Components that change together above some threshold — 60% is a reasonable starting point — belong in the same boundary, whatever the architecture diagram says.

This is more reliable than any design discussion because it is evidence about what the system actually is, not what someone intended it to be.

The usual root causes

• Boundaries drawn on technology layers. A frontend team, a backend team, a data team. Every user-visible change is a three-team negotiation by construction. Conway's Law then cements it: the org chart and the architecture reinforce each other until neither can move.
• Boundaries drawn on nouns. Entity services that each own a table and none of which can complete a business action.
• Boundaries drawn on the old org chart. A reorganisation happened; the services did not follow.

Spotify's squad model is widely copied for its team structure and rarely for the property that makes it work — boundaries drawn around things that change together, so a squad owns storage, service and client surface for one slice and can ship without asking anyone. Copies that keep layer teams get the ceremony and none of the autonomy.

The fix

Redraw boundaries around capabilities, then align teams to them — or align teams first and let the boundaries follow, which is often faster because Conway's Law is going to happen either way. Expect to merge services, not create them.