Uber reached roughly 2,200 microservices and found the estate incomprehensible. Their fix was not consolidation. What was it, and why does it generalise?

What they did

Uber's 2020 publication on Domain-Oriented Microservice Architecture describes three structural rules layered on top of the existing services — not a migration, not a consolidation:

1. Domains. Collections of related services treated as one unit. Consumers depend on a domain, not on the services inside it.

2. Gateways. Each domain exposes a single interface. Internal services can change, split and merge without any consumer knowing — restoring the encapsulation that direct service-to-service calls had dissolved.

3. Layer design. Domains sit in layers, and a domain may only depend on layers below it. The dependency rule from layered architecture, applied at estate scale.

Why the layering is the crucial part

An unconstrained service graph has no direction. You cannot tell what depends on what, a change's impact is unbounded, and failure propagation is arbitrary. Layers turn a graph into something with a topology: impact is predictable upward, and a lower layer's failure has knowable consequences.

Why it generalises

Microservices solve an organisational problem and create an architectural one. Independent deployability is genuinely valuable. Unbounded fine-grained decomposition moves complexity from inside the code — where tooling can see it — to between services, where it is harder to observe and far harder to refactor.

The general principle: there must be a unit of abstraction larger than a service. Without one, the number of things a person must hold in mind grows with the size of the estate rather than with the size of their domain. That is cognitive load acting as a hard architectural constraint.

What is most instructive

The fix was additive. Domains, gateways and layering could all be introduced incrementally against a running estate of thousands of services. A consolidation programme would have been a multi-year rewrite with no incremental value; this delivered comprehensibility one domain at a time.

When facing "our architecture has become unmanageable", the question worth asking is what structure can be added rather than what must be rebuilt — the answer is almost always cheaper and it is almost never where people start.

What a strong answer adds

Noting the parallel with Airbnb's tiered services and with Shopify's enforced module boundaries. Three organisations, three different starting points, converging on the same conclusion: boundaries need enforced dependency rules or they erode, and this is true whether the boundary is a module in one process or a service across a network.