Distributed Monolith
A system split into services that must still be developed, tested and deployed together, incurring the costs of distribution without the benefits.
The most common outcome of a poorly-executed microservices migration, and it is strictly worse than the monolith it replaced: the same coupling, plus network latency, partial failure, distributed debugging and operational overhead.
Diagnostic symptoms, any one of which is sufficient:
Services must be deployed together in a particular order for a release to work.
A typical feature requires changes in several services owned by several teams, so lead time is set by coordination rather than by engineering.
Services share a database, which makes the schema an undocumented public contract that nobody can change alone.
A shared library must be upgraded everywhere in lockstep.
Synchronous call chains several levels deep, so any failure propagates and availability multiplies downward.
Integration testing requires the whole system running together.
The causes are structural, not technical. Boundaries drawn by technical layer rather than by business capability guarantee that every business change crosses several of them. Organisational structure at odds with the architecture guarantees it too, by Conway's Law — services split across functional silos develop exactly the coordination boundaries the silos have.
Which is why the remedy usually begins with team boundaries and a modular monolith, where boundaries can be corrected cheaply before they are made expensive by distribution.