When a monolith is the right answer

The question behind the chapter

The styles in this chapter all deploy as one unit. Chapter 6 takes the same questions across a network, where every call can fail, be slow or arrive twice. Before crossing that line it is worth asking directly: when is a monolith the right answer? For much of the 2010s the industry's default answer was "rarely", and many teams split young systems into microservices because large, famous companies had done so. A decade of experience has produced a more balanced view, and this section sets it out.

The word monolith needs care. As Section 5.1 explained, it describes the deployment (one unit that is built, tested and released together), not the internal quality. A monolith can be a well-structured modular system or a big ball of mud, and the same is true of a set of services. Many of the problems blamed on monoliths are really problems of poor modularity, and splitting a poorly modularised system into services produces a distributed big ball of mud, which is worse.

MonolithFirst and the microservice premium

In May 2015 Martin Fowler described the microservice premium: microservices bring real costs of their own (automated deployment of many units, monitoring, handling partial failure, eventual consistency, versioned APIs between teams), and those costs slow a team down unless the system is complex enough for microservices to pay them back. His advice was to default to a single, well-modularised monolith and move to microservices only when complexity demands it.

A month later, in an article titled MonolithFirst (June 2015), he added two observations from the projects he had seen: almost all successful microservice systems had started as a monolith that grew too big and was then broken up, and almost all systems built as microservices from scratch had ended up in serious trouble. One reason is that good service boundaries are hard to find before the domain is understood, and a wrong boundary between services is far more expensive to move than a wrong boundary between modules. He described several routes: build a monolith and peel services off its edges later; build a deliberately disposable monolith; or start with a few coarse-grained services and split them further once boundaries settle.

The majestic monolith, and the opposing view

In February 2016 David Heinemeier Hansson, creator of Ruby on Rails, published "The Majestic Monolith" on the Signal v. Noise blog. He described Basecamp, then built by a team of about a dozen programmers, as one integrated application serving web, mobile, desktop and email clients, and argued that small teams should embrace a well-crafted monolith instead of copying the architecture of organisations with thousands of engineers. His key line was Don't distribute your computing! unless you truly have to.

Practitioners do not all agree. Also in June 2015, Stefan Tilkov argued on Fowler's site, in "Don't start with a monolith", that splitting a monolith later is often harder than expected, because its parts grow tightly coupled through shared libraries, domain objects and the database. If the system is clearly large enough to justify separate parts and the domain is well understood, he recommended designing separate subsystems from the start. The two positions are less far apart than they sound: both say the hard part is the boundaries, and a monolith whose modules are enforced from day one (Section 5.3) answers most of Tilkov's concern.

Real cases point both ways but share a lesson. Segment described in 2018 how it had consolidated more than 140 small services back into a single service after operational overhead and diverging shared libraries slowed delivery; Amazon Prime Video moved one monitoring workload from distributed serverless components to a single process in 2023 (see Section 1.3). Equally, organisations with hundreds of teams, like the large-scale cases of Section 6.3, gain real independence from services. The lesson is fit: the deployment style must match the organisation, the domain's maturity and the qualities required.

When a monolith is the right answer

A small team. With one to a few teams, the communication cost that microservices remove is low, while their operational cost is the same as for a large organisation. A monolith lets everyone understand and change the whole system.

An uncertain domain or an early product. When you are still discovering what the product is, boundaries will move. Moving a boundary between modules is a refactoring; moving it between services is a migration with data, APIs and deployments.

Strong consistency needs. A single database transaction across orders, payments and stock is simple and correct in a monolith. Across services it needs sagas, outboxes and compensation (Section 6.7).

Limited operations capacity. Each service needs its own pipeline, monitoring, alerting, scaling rules and on-call knowledge. A team without a platform for this will spend its time on plumbing.

Performance-sensitive interactions. In-process calls take nanoseconds to microseconds; network calls take milliseconds and can fail. Chatty interactions between parts of the domain are far cheaper inside one process.

In all these cases the recommended form is a modular monolith, not an unstructured one. It keeps the option to extract services open, as Section 5.3 explains.

Scaling a monolith

A common belief is that monoliths cannot scale. They scale further than most systems ever need, using the X axis of the scale cube described by Martin Abbott and Michael Fisher (running many identical copies) together with a few standard tactics. Chapter 9 treats each in depth (Section 9.1).

Horizontal replicas behind a load balancer. Run many identical copies of the application and spread requests across them. This only works if the application is stateless: sessions, uploaded files and caches must live in shared stores, so any replica can serve any request (Section 9.2). It also gives redundancy: one replica failing no longer stops the service.

Read replicas. Most systems read far more than they write. Database read replicas copy the primary's changes and serve reads such as order history and reports, at the cost of replication lag: a replica may be a fraction of a second behind (Section 7.4).

Caching. Menus, product pages and configuration change rarely and are read constantly; caching them in memory or in a shared cache removes most database load (Section 7.6). Static assets go to a CDN.

Background workers. Slow or bursty work (emails, PDF invoices, imports, payouts) goes onto a queue and is processed by worker processes. Workers usually run the same codebase with a different start command, so the system stays one codebase but the web and worker roles scale separately (Section 9.3).

Bigger machines and partitioning. Vertical scaling of the database is often the simplest next step. For very large systems, data can be partitioned by tenant or region, with a full copy of the monolith per partition (the Z axis of the scale cube). Stack Overflow is a well-known example of how far a largely monolithic design can go: according to its engineers' own write-up, on one day in February 2016 its load balancers handled about 209 million HTTP requests, with the main Q&A application (one multi-tenant application for all its Q&A sites) running on nine primary web servers, with four SQL Server machines serving the whole network.

Signs that it is time to split

Splitting should be a response to evidence, not to fashion. The signs that one deployment unit has become the constraint are mostly organisational and operational:

Team contention. Several teams change the same code and wait for each other; merge conflicts, coordination meetings and broken builds caused by other teams rise as the organisation grows. If modules are already well bounded and contention persists, deployment independence may be what is missing.

Deployment queues. Releases are batched into trains because every change needs the whole system re-tested; a small fix waits days behind unrelated work; one team's failed change blocks everyone's release.

Wildly different scaling or availability needs. One module (say, real-time courier tracking) needs fifty times the capacity of the rest at peak, or must stay up when everything else is down. Scaling the whole monolith for one module's needs becomes expensive.

Different security or compliance scope. Card data or health records may justify a separate, tightly controlled unit to keep the rest of the system out of audit scope.

Different technology needs. A machine-learning model best served from Python inside a Java monolith, for example.

Some reasons are not good reasons on their own: "monoliths are legacy", a desire to use a new technology, or slow code (which is a design problem that splitting will not fix and may make worse by adding network calls).

How to split when the time comes

Split incrementally, one module at a time, starting with the module that has both the clearest boundary and the strongest reason to leave. Modularise first if the code is not yet modular: extracting a service from a tangle drags the tangle along. Then extract along bounded contexts (Section 5.7): put a network API in front of the module's existing API, move its data to its own database, replace in-process events with a message broker and replace any shared transactions with explicit sagas. Route traffic gradually to the new service and keep the old path until the new one has proved itself.

This is the strangler fig approach and its relatives, covered in Section 11.6. The destination is often not "all microservices" but a monolith with a few extracted services where the evidence demanded it; the service-based architecture of Section 6.2 is a common, pragmatic end state.

The ratings summarise the judgements made in each section and assume typical implementations. Domain-driven design does not appear as a column because it is a method for finding boundaries, which any of these styles can use. Real systems combine styles: a modular monolith whose modules are hexagonal inside, with a pipes-and-filters import job and a microkernel for tax rules, is entirely normal.