Design Method & StylesChapter 14 · Split decisions
Monolith
Monolith
A monolith is an app built and deployed as one unit. Inside it, features call each other as plain function calls, share one database and can change together in one transaction, so it's simple to build, test, deploy and refactor. It starts to hurt when many teams share it — every change ships the whole thing, one team's release waits on another's, and the whole app has to scale together. Messy code is a separate problem; splitting it into services doesn't fix that.
- Use when
- A new product whose domain and boundaries are still being learned · One team, or a few teams that can share a release · Features that need to change data together in one transaction
- Avoid when
- Many teams that keep blocking each other's releases on one shared deploy · Parts with very different scaling or uptime needs that can't be met by scaling the whole app
- Trade-offs
- Fast, reliable in-process calls and one transaction, in exchange for one shared release for everyone · Simple to run (one pipeline, one thing to monitor), but the whole app scales as one block · Easy to refactor across features, and just as easy to let boundaries erode without discipline
- Requires
- Split app and database tiers
3 objectives · 5 misconceptions
- explain Explain what one deployable unit gives for free — in-process calls, one transaction across features, one pipeline, easy refactoring — and what each would cost once split.
- predict Predict which of a struggling monolith's pains a split into services would relieve — deployment ones (a shared release, scaling everything, one team blocking another) — and which it wouldn't — structure ones (tangled code with no boundaries).
- choose Choose whether a new product like Checkout should start as one deployable unit, and name the signals that would justify splitting it later.
- Not true: A monolith is old, badly built code that should be replaced.
- Not true: Splitting a tangled monolith into services makes the code cleaner.
- Not true: A monolith can't scale — it runs on one server.
- Not true: A new product should start with microservices so it won't need rewriting later.
- Not true: A monolith has no internal structure — it's one big pile of code.
Practice
No katas practise this yet.