Distributed Monolith
A system split into services that must still be deployed, changed and operated together, incurring distribution costs without independence.
The most common failure of microservice adoption, and it is worth naming precisely because teams in this state often believe the problem is insufficient tooling.
The symptoms are unambiguous. Services must be released in a specific order, or together. A typical feature requires changes to several services in one sprint. Services share a database or read each other's tables. Local development requires running most of the estate. One service being down makes several others fail. And integration testing requires an environment with everything in it.
The cause is boundaries drawn without regard to how change actually flows through the system, usually by splitting on technical layers or on entities rather than on capability and change rate.
The result is genuinely worse than the monolith it replaced: all the coupling, plus network latency, plus partial failure, plus distributed debugging, plus operational overhead per service, plus deployment coordination that is now harder because the components deploy separately.
The honest remedy is usually to merge services back together and re-split later along better boundaries, which is organisationally difficult because it reads as failure and is almost always the right call. The alternative — attacking the symptoms with more orchestration, more tracing and more sophisticated release coordination — makes the system more elaborate without addressing why the coupling exists.