A system meets every SLO but the business is unhappy because feature delivery has slowed to a crawl. What is being measured wrongly, and when is reducing distribution the right scalability investment?

What is being measured wrongly

The SLOs measure the system's behaviour and say nothing about the organisation's ability to change it. A frozen system has perfect availability. Reliability metrics are necessary and are not sufficient, because they are all lagging indicators of runtime and blind to the cost of change.

What to measure instead

• Deployment lead time — commit to production. Sustained growth here is the clearest signal.
• Change failure rate and time to restore, which together say whether slowness is caution or chaos.
• Deployment frequency per service, and specifically the number of services that must be released together for a typical feature. This is the coordination-cost metric and it is rarely instrumented.
• Cross-team dependencies per feature — how many teams must agree before a change ships. Lead time is usually dominated by waiting for other teams, not by engineering effort.
• Time spent on operational toil per team, which is where per-service overhead surfaces.

The diagnosis

If a typical feature touches five services owned by three teams, the bottleneck is coordination, and no amount of runtime optimisation touches it. The system was decomposed for scalability of machines and the binding constraint turned out to be scalability of decisions.

When reducing distribution is the right investment

When the evidence shows:

• Change coupling: services that consistently release together, visible in deployment history.
• No independent scaling need: the merged components have similar load profiles and neither is a bottleneck.
• No isolation requirement: they already fail together in practice, so the boundary buys nothing.
• Ownership dilution: teams owning more services than they can hold in their heads.

Then merging services reduces coordination cost directly, and it is a scalability investment — in the dimension that is actually binding.

The counter-case

If lead time is dominated by manual approval gates, slow test suites, environment scarcity, or unclear ownership, merging services fixes nothing. Diagnose before restructuring: the same symptom has several distinct causes, and re-architecting is the most expensive of the available responses.