An organisation decomposed into thousands of microservices during hypergrowth and later consolidated into coarser domain groupings. Was the original decision wrong?

What is being tested

Whether you can hold two ideas at once: that a decision was right when made, and that it is wrong now. Junior reasoning insists one of those must be false.

The reasoning

Uber's decomposition during hypergrowth bought a specific thing: teams shipping independently while headcount was growing faster than any coordination mechanism could absorb. At a few hundred engineers, that was worth a great deal, and the overhead of a few dozen services was modest.

It also sold something, and the price of what was sold rose over time. With thousands of services:

• Understanding a cross-cutting flow requires reading many codebases, and no single team owns the end-to-end behaviour a customer experiences.
• The fixed operational cost per service — pipeline, on-call, dashboards, dependencies, security patching — multiplies by a number that keeps growing.
• Changes that span a business capability require negotiation across many owners, which is the coordination cost that the decomposition was meant to eliminate, reappearing at a different layer.

So the same decision has a different value at 200 engineers and at 4,000. That is not hindsight bias; it is the ordinary behaviour of a trade whose terms depend on scale.

The transferable practice

Record the conditions under which a decision should be revisited. Most architecture decision records state context, choice and consequences, and stop. The missing section is: what would have to be true for this to become the wrong choice?

"We are splitting into services to remove the release-train bottleneck at 300 engineers. We should revisit this if the average service has fewer than two committers, if cross-service changes exceed a third of our features, or if operational overhead per service exceeds X engineer-days per quarter."

Written that way, the revisit is triggered by evidence rather than by an outage or a new CTO.

What the wrong answers reveal

"They should have predicted the end state" assumes an organisation can know its five-year headcount and domain boundaries at the moment it is growing fastest and understands its domain least. That is not available.

"Microservices are always wrong here" mistakes a scale-dependent trade for a universal law, which is the same error in the opposite direction.

The senior framing

Architecture is a portfolio of purchases made under uncertainty. The measure of quality is not whether every decision aged well — none do — but whether the decisions were priced honestly, whether the exit conditions were written down, and whether the organisation was capable of noticing when a price changed and acting on it. Consolidating thousands of services is expensive; it is much cheaper than not noticing.