Splitting a monolith is usually sold as removing complexity — smaller services, clearer ownership, independent deploys. What it actually does is trade one kind of complexity you already understood for a different kind you have not built the tooling for yet. Teams that regret the split are, almost without exception, the ones who budgeted for the first and got surprised by the second.
The transaction you used to get for free
Inside a monolith, "update the order and decrement the stock" is one database transaction — it either both happens or neither does. Split across two services, that guarantee is gone by default. You are now choosing between eventual consistency with a reconciliation job, or a distributed transaction pattern like sagas, and both are real engineering work that the monolith gave you for nothing.
We make teams write out, service by service, every operation that currently spans two tables that would live in different services after the split. If that list is long, the split is premature — not impossible, just premature, because each entry on that list is a project of its own.
Debugging across a network boundary
A stack trace inside a monolith tells you exactly what happened. A failure across three services tells you a request timed out somewhere, and finding out where means distributed tracing, correlation IDs threaded through every call, and log aggregation that was previously optional. None of this is exotic anymore, but it is infrastructure that has to exist before the split, not infrastructure you build reactively after the first three-hour incident where nobody could tell which service was actually slow.
X-Request-Id: 7e1c-… (propagated through every downstream call)
order-service 200 84ms
stock-service 200 1240ms <- the actual problem
notify-service timeout 3000ms (cascading from stock-service)Deploys get faster, coordination gets slower
The genuine win is real: a team can deploy their service without waiting on everyone else's release train. What gets lost is the coordination that used to be implicit — a shared compiler catching a breaking interface change at build time. Across services, that same breaking change ships silently until a consumer fails at runtime, unless you invest in contract testing between services up front.
- Contract tests between producer and consumer services, run in CI before either can deploy.
- A shared schema registry for events, versioned, so consumers are not surprised by a field disappearing.
- One team clearly owns each service — shared ownership across services reliably means no ownership.
When the split is worth it
We recommend the split when a specific part of the system has genuinely different scaling needs, a genuinely different release cadence, or needs to be owned by a genuinely separate team — not because "microservices" is the more modern-sounding architecture. If none of those three are true yet, a well-organized modular monolith gets you most of the maintainability win without paying the distributed-systems tax before you need to.
