A team split a monolith into 14 services. Every feature now touches 4 or 5 of them, and releases are coordinated weekly. What would you change?

What the interviewer is testing

Whether you can diagnose a distributed monolith and propose the unpopular but correct remedy.

The diagnosis

The boundaries are wrong. A feature touching four or five services and requiring coordinated weekly releases means the services are not independently deployable — which was the entire point of splitting.

They now have every cost of distribution — network latency, partial failure, distributed debugging, per-service operational overhead, eventual consistency — and none of the benefit.

The likely cause is splitting along technical layers or entities rather than along capability and rate of change. A data service, a business logic service and an API service produce maximum coupling, because every feature touches all three.

What I would change

Merge services back together where they change together. This is organisationally difficult — it reads as admitting failure — and it is usually the right call. Fourteen services for a system with this coupling profile is probably three or four.

Re-split later on evidence, using rate of change as the primary signal: instrument which services change together over six months, and the natural boundaries become visible in the data rather than being guessed.

Draw boundaries by data ownership. The test is not "can we extract this code" but "can this service own its data exclusively, with no other service reading its tables". If the answer is no, it is not a service.

Consider a modular monolith as the target for most of it: one deployable with automatically enforced internal boundaries, keeping domain separation while removing the network. Extract only the specific modules with a genuine independent need — different scaling, different technology, a separate team, a distinct compliance boundary.

What a strong answer adds

The metric that makes the argument objectively: how many services must change to deliver a typical feature? Instrument it. If it is routinely more than one or two, the boundary is in the wrong place, and the number is far more persuasive than an architectural opinion.

And a caution against the alternative response — investing in better orchestration, tracing and release coordination — which makes the system more elaborate without addressing why the coupling exists.

Common weak answers

More sophisticated release automation. Adding an orchestration layer over the 14 services.