Monolith First
Start with a well-structured monolith; split into services only once the boundaries and the need are proven.
“Almost all the successful microservice stories have started with a monolith that got too big and was broken up”
To an executive
Splitting a new product into many parts too early adds cost before we know where the right divisions lie. Starting simple reaches customers sooner and lets us learn first.
To an engineer
Build a well-structured, modular single codebase first. Extract a service only when its boundary has proven itself and you can name the specific problem it solves.
The idea
Fowler observed that almost all the successful microservice stories he had heard began with a monolith that grew too big and was broken up, while systems built as microservices from scratch often ran into serious trouble.
The reason is boundaries. You rarely know the right service boundaries for a new domain. Refactoring across modules in one codebase is cheap; refactoring across network-separated services is expensive. A monolith lets you discover the boundaries before you commit to them.
Fowler described several ways to follow this: build a carefully modular monolith, extract services gradually from the edges, treat the first monolith as sacrificial, or start with a few coarse-grained services. He was clear that the evidence was early and that some experienced teams argue the other way.
Why it works
Early on, speed of learning matters more than architecture. Most new products have not yet proved they are needed. A single codebase lets you change direction quickly.
Boundaries are discovered, not designed. Your first guess at the domain split is likely to be wrong. Moving a boundary inside one codebase is a refactoring; moving it between services is a project.
It avoids paying the microservice premium too early. Distribution costs arrive on day one, while its benefits only come with scale.
Where it applies
- New products and greenfield systems, especially in unfamiliar domains.
- Small teams, which cannot yet benefit from independent deployment.
- Rewrites, where a team may be tempted to "do it properly with microservices" this time.
How to apply
- Start with one deployable and clear internal modules aligned to the domain.
- Enforce module boundaries in code, for example with package rules or architecture tests.
- Watch for proven boundaries: modules that change independently, have stable interfaces, and have a clear owner.
- Extract a service only when a module has such a boundary and a concrete reason: independent scaling, release cadence or team ownership.
Example scenario
A startup launched with 14 microservices. Every feature crossed four of them, and within months the boundaries had proved wrong: two services shared most of their data, and one was split down the middle of a single business process.
The team merged them into a modular monolith with enforced module boundaries, and feature lead time roughly halved. A year later, two modules with stable interfaces and very different scaling needs were extracted as services, this time with confidence.
Questions to ask
- Do we understand the domain boundaries well enough yet to fix them behind a network?
- What concrete problem would splitting this out solve, and for whom?
- Is our monolith modular enough that we could extract a service next quarter if we needed to?
When not to use it
- Replacements of well-understood systems, where the domain boundaries are already known.
- Teams already experienced with microservices and with a platform that keeps the premium low.
- Organisations that must scale to many teams immediately, where independent ownership matters from the start.
How it misleads you
Using it to justify a big ball of mud. Monolith first only works if the monolith is modular. Fowler noted that many monoliths become so entangled that they cannot be split later; without enforced internal boundaries, "first" quietly becomes "forever".
In the wild
Further reading
Last reviewed · Suggest an improvement