Why Microservices Fail: The Distributed Monolith Trap

Microservices do not fail because the pattern is bad. They fail because teams skip the boring parts: service contracts, ownership boundaries, observability that spans services, deploy ordering, and the schema migration choreography that lets two services evolve their shared events without breaking each other.

What you end up with is a distributed monolith. The code is in eight repos, but every feature still requires changes in five of them. You get microservices in deployment and a monolith in coupling. The worst of both worlds: the operational complexity of distributed systems, with none of the independent-deployment payoff that justified the split.

The right way to think about service boundaries is Conway's Law, run in reverse. Team boundaries become service boundaries, whether you wanted them to or not. If three teams own one service, your service contract is now a Slack channel. If one team owns three services, the "boundary" between those services is whatever that team finds convenient on Tuesday.

The production failure I have watched up close. A team took a 50K-line backend and split it into eight services along technical lines: an auth service, a user service, a notifications service, a billing service, and so on. The team structure did not change. Every product story still touched three or more services. Every release required coordinating deploys across multiple repos, in a specific order, with a specific migration sequence. Release cadence dropped from twice a week to once every two weeks. Two engineers spent half their time writing release runbooks. After a year, the team merged six of the services back into a single deployable. Velocity recovered within a sprint.

The fix is not "do not use microservices." The fix is to align service boundaries to team ownership, not to engineering aesthetics. If two services are always changed together, they are one service that you have made painful to deploy. If a service has no team that wakes up for its pager, it is not a service, it is a shared library with extra latency.

The other boring rules still matter: one data store per service, stateless nodes, container-based deploys, domain-driven boundaries, an orchestration layer for routing and retries. Independent build pipelines so a fix in one service ships without a coordinated train. A shared observability layer so a request that crosses six services is still one trace. None of those rescue you from a team topology that wants to be a monolith, but they make a well-shaped split survivable instead of merely painful.

Fix the org chart first. Then split the code. Microservices reward the orgs that already had clean ownership, and punish the ones hoping the split itself will create that clarity.