Architecture · 8 min read
Why Getting Service Boundaries Wrong Is Worse Than Staying with the Monolith
The most expensive microservice mistake is not picking the wrong framework — it is drawing the wrong boundaries. Here is how to think about them correctly.
The Real Cost of Wrong Boundaries
The most common misconception about microservices is that splitting a monolith into many services automatically improves things. It does not. If the boundaries between services are drawn incorrectly — if they cut across natural cohesion rather than along it — you create a distributed monolith: all the operational complexity of distributed computing with none of the independence that justifies it.
A distributed monolith is worse than the original monolith. You now have network latency between components that were previously in-process calls. You have distributed transactions where you previously had database transactions. You have deployment coordination problems that are harder to manage than they were before, because now they span service ownership boundaries.
The question is not "should we split this?" but "where should the splits be?"
What a Boundary Should Actually Reflect
A service boundary should reflect a business capability — a set of related functions that change together, for the same reasons, owned by the same team. This is what Domain-Driven Design calls a bounded context.
When you draw boundaries along business capabilities rather than technical layers, two things happen:
First, the services become independently deployable in practice, not just in theory. If Service A and Service B must be deployed in lockstep because changing Service A's data model also requires changes to Service B, your boundary is in the wrong place.
Second, team ownership becomes coherent. A team owns a service because they own the business capability it encapsulates. They understand it, they can reason about its behavior, and they can evolve it independently. When a team owns a service that does not map to any coherent business concept, they are just maintaining a deployment unit — not a system component with a clear purpose.
The Conway's Law Constraint
Conway's Law states that the structure of a system tends to reflect the communication structure of the organization that builds it. This is not just an observation — it is a design constraint.
If your organization has three backend teams that share a monolith, decomposing into microservices will not produce ten cleanly independent services. It will produce three clusters of services that are tightly coupled within the cluster and loosely coupled across clusters — because that reflects the team structure.
Ignoring this produces friction at every interface. Teams coordinate across service boundaries because the services do not reflect who owns what. APIs are designed to accommodate shared access rather than clean contract interfaces.
Effective microservice adoption requires thinking about team topology alongside service topology. The service boundaries and the team ownership boundaries should align. If they do not, one of them will force the other into an uncomfortable shape.
How to Identify Correct Boundaries in Practice
Start with data ownership. A service should own its data. If two services need to read and write the same table, they are not separate services — they are two processes sharing a service boundary. Move the data into one service or extract a third service that owns the data and provides an API to the other two.
Follow the rate of change. Components that change for different reasons should be separate services. A pricing engine that changes with business logic and a notification dispatcher that changes with communication channel preferences have different change drivers — they are good candidates for independent services.
Map the failure domains. Ask: if this service goes down, what else breaks? If the answer is "a lot of unrelated things", the service is too central — it has absorbed responsibilities that belong elsewhere. If the answer is "nothing critical, and we have a reasonable fallback", the boundary is probably drawn correctly.
Validate with the team structure. Who will own this service? Is there a team with the context to maintain it, evolve it, and be on-call for it? If the answer is "several teams will share ownership" — that is a boundary problem, not an ownership problem.
What to Do If You Have Already Made the Wrong Cuts
If you are operating a distributed monolith today, the path forward is not to re-merge everything and start again. It is to gradually re-draw the boundaries.
Identify the worst coupling points — the synchronous dependencies between services that make deployments coordinated, or the shared databases that make schema changes ripple across services. Address those one at a time, introducing proper event-based communication or consolidating data ownership before splitting again more cleanly.
This is slower than starting over. But starting over in production, for an active system, is rarely a real option. Incremental re-alignment almost always produces better outcomes than a big-bang redesign.
Service boundaries are the most consequential architectural decision in a microservice system. Get them right, and everything else becomes tractable. Get them wrong, and no amount of framework selection, tooling choice, or DevOps investment will fix the underlying coupling. The boundary is the architecture.