10.3 Monoliths, microservices and the honest trade

What this is and why it exists

This is the argument the industry has been having for a decade, and it is worth being able to reason about rather than take a side in. The useful skill is not knowing which is better — neither is — but being able to say which one a particular team should build, on which evidence, and then to recognise the failure mode that produces the worst of both. That failure is common, it has a name, and most teams reach it by accident.

The vocabulary

• Monolith — one deployable application containing the whole system.
• Modular monolith — the same, with strong internal boundaries between parts.
• Microservices — many small services, each deployed independently.
• Independent deployability — being able to release one part without releasing the others; the actual point of the split.
• Operational tax — the fixed cost each additional service adds: pipeline, monitoring, alerting, on-call, deployment, security review.
• Service boundary — the line dividing one service's responsibilities and data from another's.
• Distributed monolith — services that must be deployed together, giving network costs with none of the independence.
• Serverless — the same spectrum's far end, where the unit is a function rather than a service.

The mental model

A monolith is one thing you deploy. It is not a synonym for badly written, and this is the misunderstanding at the root of the whole argument: most successful large systems started as monoliths, and many remain them. Inside one codebase, a call is a function call — fast, transactional, debuggable in one stack trace — and a change spanning three areas is one commit, one test run, one release. Refactoring a boundary is a rename. Those are enormous advantages and they are usually described as "legacy" by people who have not had to give them up.

Microservices buy exactly one thing that matters, and it is worth naming precisely: independent deployability. One team can release its part without coordinating with four others. Everything else people list — scaling, technology choice, fault isolation — is real but achievable in other ways, whereas independent release is not. So the honest question when someone proposes a split is: which teams are currently blocked waiting for each other? If the answer is none, the split is buying something you do not need.

Because the cost is a tax, and it is charged per service, forever. Each service needs a pipeline, a repository, monitoring, alerting, a place in the on-call rota, a deployment story, dependency updates, and a security review. Ten services is not ten times one service's code; it is ten times the operations. And what was a function call becomes a network call, which means it can now be slow, fail, time out, be retried, and arrive twice — all of which you now handle deliberately, in every direction. A three-person team running twelve services is spending most of its time being an operations department for itself.

Boundaries, when you do draw them, follow data ownership rather than the organisation chart. A service should own its data exclusively — nothing else reads or writes that store directly. Draw the line anywhere else and you get services that must change together because they share tables, which is the failure below. Two questions expose a bad boundary quickly: can this service be deployed on its own without breaking anything, and does any other service read its database?

Which brings the distributed monolith, the outcome to fear. Services that must be released together, that share a database, that break when one is unavailable, and that call each other in long synchronous chains. You have paid the entire operational tax and received none of the independence, and every incident now spans several repositories. The route there is always the same: a monolith split along technical layers rather than along ownership, or split early, before anybody knew where the boundaries were.

Serverless sits at the far end of the same spectrum, and it is worth seeing it that way rather than as a separate religion. The unit gets smaller, the operations move further to the provider, the independence increases, and the coordination problem increases with it — a system of two hundred functions has the same "where does this flow live" difficulty as a system of forty services, arriving sooner. Functions are excellent for genuinely independent, event-shaped, intermittent work. They are a poor container for a system's core logic, for the same reason microservices are: the shape imposes coordination costs that the work itself did not require.

What you should now be able to explain or do

Say what a monolith actually is and name three concrete advantages of one codebase. Name the single thing microservices buy that cannot be bought another way. List six items in the per-service operational tax. Draw a service boundary on data ownership and test it with the two questions. Recognise a distributed monolith from its symptoms and say how teams get there. Place serverless on the same spectrum and say what it is and is not good for.

Check yourself