Why Your Microservices Are a Monolith
Distributed doesn't mean decomposed. Most service architectures share more state than they admit.
A distributed system that must be deployed in lockstep is a monolith with network latency.
The promise of microservices was independent deployment, independent scaling, and independent evolution. The reality, in most organizations, is a set of services that share a database (or its moral equivalent), require coordinated releases, and fail together when any one of them fails.
The shared-state test
There is a simple test: can you deploy service A without coordinating with service B? If the answer is no, the boundary between them is not real. They are one system, distributed across multiple processes.
How this happens
It happens gradually. A shared database schema that “only one service writes to.” An event format that embeds assumptions about the consumer’s data model. A deployment pipeline that runs all services together “for safety.”
Each compromise is individually reasonable. Together, they recreate the monolith.
What actual decomposition requires
Real decomposition requires real boundaries. Each service owns its data completely. Contracts between services are explicit and versioned. Deployment is genuinely independent.
This is harder than it sounds. Most teams underestimate the discipline required. But the alternative is a distributed monolith — which combines the complexity of microservices with the rigidity of a monolith, delivering the benefits of neither.