Your organisation has grown to 2,000 microservices. Teams report that understanding and changing the system is now harder than before decomposition. What do you do?

What the interviewer is testing

Whether you recognise that service count past a threshold is a cost, and whether you can propose structure above the service level.

The diagnosis

The benefits of microservices — independent deployment, clear ownership, technology freedom — are achieved at a certain number of services and do not increase beyond it. The costs continue to grow.

At two thousand: no coherent view of what depends on what, changes requiring coordination across many services, onboarding requiring knowledge of dozens, and no architectural constraint on which service may call which — so the dependency graph is arbitrary, and arbitrary graphs cannot be reasoned about, tested in isolation or safely changed.

What to do

Group services into domains with a published interface. Consumers depend on the domain, not on the services inside it, so internal restructuring does not break callers. This is what Uber's Domain-Oriented Microservice Architecture introduced after reaching roughly this scale.

Impose layering with dependency rules — a service in one layer may depend on lower layers but not upward — and enforce it automatically. This is what makes blast radius analysable.

Merge services that always change together. Instrument which services co-change over six months; the natural boundaries appear in the data. Many of the two thousand are almost certainly fragments of what should be one service.

Retire what is unused. At this count, a meaningful number have no meaningful traffic.

The constraint to accept

Domains reintroduce a coordination boundary and a gateway hop, and defining domain boundaries has the same difficulty as defining service boundaries with higher stakes. This is deliberately trading some autonomy for tractability.

What a strong answer adds

The two diagnostic questions that make the argument objectively rather than aesthetically:

How many services does a typical feature touch? If routinely more than one or two, the boundaries are wrong regardless of count.

Is there any rule constraining which service may call which? If not, that is the first thing to introduce, because it is what makes every subsequent improvement possible.

And the lesson for organisations not yet at this scale: structure above services is easier to impose early than to retrofit at two thousand.

Common weak answers

Better documentation and diagrams. A service mesh, which adds observability to the problem without addressing the structure.