What is the 'monolith-first' heuristic often attributed to Martin Fowler, and what's the reasoning for starting a new system as a monolith even when the team expects it will eventually need to scale like microservices?

## The heuristic The "monolith-first" heuristic, popularized by **Martin Fowler** and **James Lewis** in their writing on microservices, is a sequencing rule for how to build a new system: 1. start with a single, well-structured deployable application (ideally a modular monolith) 2. run it in production long enough to learn where the system's real domain boundaries lie 3. only then extract the pieces that turn out to need independent deployment, scaling, or team ownership into separate services It is explicitly a rule about new, unproven systems — not a blanket claim that monoliths are always better than microservices. ## The cost of being wrong The reasoning comes down to the cost of being wrong about boundaries at two different points in a system's life. Early in a new product, nobody reliably knows where the seams in the domain actually are; requirements shift, the team learns what the product needs to do, and "obvious" module boundaries drawn on day one are frequently wrong once real usage arrives. - **In a monolith, a wrong boundary is cheap to fix**: it's a refactor inside one codebase, executed inside the safety of the compiler and a single test suite, with no data migration across a network and no coordination with another team's release schedule. - **In a microservices architecture, a wrong boundary is expensive to fix**: two services that turn out to be too tightly coupled need their APIs renegotiated, their data potentially re-merged across a network boundary, and their independent deployment pipelines reconciled — all while both are already running in production. Fowler's framing is that you should only pay for microservices' fixed costs once you have evidence, not a guess, about where the boundaries should go. ## What deferring the split costs The trade-off is not free. Deferring the split means accepting, for a while, the coupling costs of a monolith: - a build that grows slower as the codebase grows - a release train that couples unrelated features - a temptation for boundaries to blur without the hard stop of a network call to enforce them — which is why monolith-first is usually paired with building a modular monolith, not an unstructured one It also means later splitting out a service is real work — identify the seam, extract the code behind a stable API, split or replicate the underlying data, and migrate callers, typically using patterns like the **strangler fig** to do it incrementally rather than as a risky rewrite. ## Failure modes on both sides The failure mode on one side is well-documented: teams that go straight to microservices for a brand-new, unproven product often draw service boundaries around their initial (wrong) guess of the domain model, then spend the next year paying network and coordination overhead to work around boundaries that don't match reality — the **"premature microservices"** trap, which frequently produces a distributed monolith (many services, but so tightly coupled they must deploy and scale together) rather than the intended independence. The failure mode on the other side also exists: teams that never revisit the decision once the product and boundaries have actually stabilized, and end up with a large, tangled monolith long past the point where splitting would have paid for itself, usually because nobody enforced module boundaries inside it and "we'll split it later" never had a concrete trigger. ## Where it shows up A widely cited real example is **Segment's** public postmortem of their own microservices migration: they split their core data-pipeline into more than 100 services early on, expecting independent scaling benefits, and later found that most services had highly correlated load and were so interdependent that on-call engineers had to reason about the whole graph anyway — so they consolidated back into a smaller number of services, effectively re-discovering the monolith-first lesson after the fact. Conversely, companies with well-understood, previously-built domains — for example, a team standing up a payments processor that mirrors a bounded context they've operated elsewhere — can reasonably start with a small number of services from day one, because the "we don't yet know the boundaries" assumption underlying monolith-first doesn't hold for them.