Design
When does a monolith end?
Not at a size. At a set of observable symptoms that network boundaries would actually treat. The checklist we use, with the false positives labeled.
By TIS Partners · · 2 min
The question arrives at every review eventually, usually phrased as "when should we start breaking it up," as if decomposition were a maturity milestone rather than a treatment. Our answer: a monolith ends when it exhibits specific symptoms that a network boundary treats, and not before. Size is not a symptom.
Which symptoms actually indicate the treatment?
We recognize four. Deploy contention: teams queue behind each other's releases, and the queue is measured in days; the batch integrates everyone's risk, and boring deploys become impossible at any batch size. Divergent scaling economics: one workload needs 40 GB of memory per instance and another needs 400 instances, and the union of both requirements prices the fleet. Genuine fault isolation needs: a background report generator that can take down checkout by exhausting a shared pool is a boundary argument written in incidents. And organizational scale past what shared ownership bears, the Conway pressure that no code structure fixes.
Note what is absent: "the build is slow" (a build problem), "the code is a mess" (a mess travels over networks perfectly well), "hiring says microservices" (hiring says many things). Martin Fowler's monolith-first argument has aged into consensus for a reason: boundaries drawn before the domain is understood are guesses, and network guesses cost more to revise than module guesses.
What would have to be true for the split to succeed?
More than most teams check. The candidate seam should already be visible in the code as a module with a narrow interface; if the seam must be manufactured and distributed simultaneously, the project is doing surgery and moving house at once. The data must separate: a "service" that shares tables with its parent is a deployment unit, not a boundary, and it inherits every coordination cost while adding a network. And the team must be able to state the decision the boundary hides, in one sentence, without the word "scale" doing unsupervised work.
What does ending look like when it goes well?
Gradual, and slightly boring. One capability leaves at a time, chosen because a symptom named it, behind a routing layer that permits retreat. The ledger of what moved and why lives in decision records. Two years later the shop has four services and a smaller monolith that nobody resents, rather than forty services and a distributed system that nobody understands.
The monolith does not end the way an era ends. It ends the way a lease ends: clause by clause, when the terms stop fitting, with the paperwork done. Anything more dramatic is usually a rewrite wearing a microservices costume, and rewrites have their own famous failure modes.