Coordination Cost

The time a change takes is rarely the time to write it. It is the time to agree on it, to schedule it across the teams that own the affected components, and to release those components in a compatible order.

Coordination cost grows with the number of independently-owned components a typical change touches, which is a property of how boundaries were drawn — and therefore an architectural quantity, not a management one.

Why it matters

Reliability metrics are all green in a system that has become impossible to change, because a frozen system has perfect availability. Teams instrument runtime behaviour exhaustively and delivery friction not at all, so the failure mode is invisible in every dashboard while being obvious to everyone doing the work.

Coordination cost is the scalability dimension that most often turns out to be binding at large scale, and no amount of runtime optimisation touches it.

Implementation patterns

• Instrument services-per-change: from deployment history, how many services release together for a typical feature. This is the core metric and almost nobody has it.
• Instrument teams-per-change, which is the same measure at the level that actually causes waiting.
• Mine change coupling from version control — files and services that consistently change in the same commit or the same week are coupled regardless of what the architecture diagram claims.
• Track deployment lead time and change failure rate together, so that slowness can be distinguished from caution.
• Align boundaries to teams deliberately rather than discovering the alignment after the fact. Conway's law is not a warning; it is a design tool — draw the boundaries you want the teams to have, or accept the boundaries the teams will impose.
• Reduce distribution when the evidence supports it: merge services that release together, have similar scaling profiles, and already fail together.

Industry example

Netflix's move from a very large number of fine-grained services toward fewer, better-bounded ones is a coordination-cost decision rather than a runtime one. The signals are the familiar set: features requiring lockstep releases across several services, deep synchronous call chains where availability is the product of the members', and teams owning more services than anyone could hold in their head.

The safe execution order matters as much as the decision: merge the code first with internal module boundaries preserved — reversible — then collapse the call in-process, and unify the data last, because that is the irreversible step.

Failure scenarios

• Lockstep deployment accepted as normal, so the cost compounds silently.
• Green SLOs used as evidence of architectural health, hiding a delivery collapse.
• Restructuring without diagnosis, when the real cause was manual approval gates, slow tests, environment scarcity or unclear ownership — the same symptom with a far cheaper fix.
• Merging services and losing the internal boundaries, producing something that cannot be split again.
• Unifying data early in a consolidation, removing the ability to roll back.
• Consolidation as a target — a service-count goal is the same error as a microservice-count goal, pointed the other way.

Trade-offs

Reducing distribution lowers coordination cost and gives up independent deployability, independent scaling and fault isolation for the merged components. That trade is correct precisely when those three things were not actually being obtained — when the services already deploy together, scale together and fail together, the boundary is charging full price and delivering nothing.

Where they are being obtained, the coordination cost is the price of real isolation and is worth paying. The judgement is entirely about which of those two situations you are in, and it is answerable from data.

Interview question

"Every SLO is green and the business says we have stopped shipping. Tell me what you would measure in the first week, what you would conclude from each possible result, and under what evidence you would recommend merging services rather than fixing the pipeline."