Cloud Parts

Monoliths

The whole application is built, tested and deployed as one unit, usually with one database.

Live model
What you’re watchingEvery copy runs the whole application. The load balancer hands requests to the copies in turn, and all of them read and write the same database. When copy 2 restarts with a new version, the other two keep serving.

How it works

A monolith is one deployable program. The web pages, the API, the business rules and the background jobs live in one codebase, build into one artifact and usually share one database. Inside, parts call each other as ordinary function calls in the same process, so a call takes nanoseconds, a change that touches orders and billing can sit in one database transaction, and there is one test suite, one pipeline and one thing to monitor. To handle more traffic you don’t split it: you run several identical copies behind a load balancer, and the database becomes the part you scale with care. The cost shows up as the code and the team grow. Any change means rebuilding and redeploying the whole application, the full test suite gets slow, and without enforced boundaries any module can reach into any other, so a change in tax code can break shipping. A **modular monolith** keeps the single deployable unit but splits the code into components with public interfaces and their own tables, and uses tooling to stop components from calling each other’s internals.

Think of it as

A family restaurant with one kitchen. Everyone shares the same fridge and stove, so making a new dish is quick, and it can grow busier by opening more identical branches. When the menu reaches two hundred dishes and forty cooks, people start tripping over each other unless each station keeps to its own counter.

Reach for it when

  • A new product, while you’re still finding out what users need and where the boundaries are
  • One team, or a few, working on one codebase
  • Data that must change together in one transaction, such as an order and its payment
  • You want the fewest moving parts to deploy, monitor and pay for

Think twice when

  • Many teams block each other on one release train and the build takes too long for anyone to own
  • One part needs very different scaling or hardware, such as GPU work next to a CRUD app
  • Parts need different languages or runtimes that can’t share a process

A real example

A booking site runs one Rails app: pages, API and background jobs. Three identical copies sit behind a load balancer and share one PostgreSQL database. A deploy replaces the copies one at a time with the new build. When traffic doubles on a Friday, the team adds two more copies; the database, not the app, is the thing they watch.

Monoliths in production#

Basecamp

since 2003

David Heinemeier Hansson has written Basecamp as one application since 2003. In 2016 it served web, iOS, Android, Mac, Windows and email from one codebase with about 12 programmers, 200 controllers and 190 model classes.

Shopify

modular monolith

Shopify’s core Rails monolith has been developed since at least 2006. Rather than split it into services, Shopify reorganised it from 2017 into components with public interfaces, and wrote Packwerk to flag code that reaches across boundaries. By 2020 it held over 2.8 million lines of Ruby.

Prime Video stream monitoring

2023

Amazon Prime Video moved one service, which checks live streams for defects, from Step Functions, Lambda and S3 into a single process on ECS. Passing frames in memory instead of through S3 cut its infrastructure cost by over 90%. They called it a case-by-case decision, not a rule.

Often confused with

MicroservicesServerless architectureServerless functions (FaaS)Load balancersRelational databasesService layerMonolith, microservices or serverless?
Where it came from2003–2023

For most of computing history, “the application” simply meant one program, so there was no need for a word for it. Amazon.com started in the mid-1990s as one program, Obidos, running on a web server in front of a database. It came to hold all the business and display logic, and by 2001 it was clear it couldn’t scale any more: unrelated code shared resources, nobody clearly owned anything, and the shared databases were hard to scale too. Amazon broke it into services, and Netflix later did the same. When James Lewis and Martin Fowler defined microservices in March 2014, they described the monolith as their foil: a single logical executable that you scale by running many instances behind a load balancer, where any change means rebuilding and redeploying the whole thing.

The pushback came fast. In June 2015 Fowler wrote “MonolithFirst”: almost every successful microservice story he’d heard began with a monolith that got too big, while systems built as microservices from scratch often ended up in serious trouble. In February 2016 DHH published “The Majestic Monolith”, arguing that patterns made for organisations with thousands of developers hurt small teams, and that the first rule of distributed computing is not to distribute it.

Large companies started to look for a middle path. Shopify outgrew its unstructured monolith in 2016, but instead of splitting it into services it built a modular monolith: one deployable unit with enforced boundaries between components. In 2023 an Amazon Prime Video team wrote that moving one service from serverless microservices back into a single process cut its cost by over 90%, and the post set off a new round of argument.

Why it’s built this way

One process, so parts call each other directly
An in-process call needs no network, serialisation, API versioning or retry logic. Shopify listed this as one of the strongest reasons to stay a monolith: no backward-compatibility work and no slow calls between components.
One shared database
A single database makes any data a query away and lets one transaction cover several parts of the business. The price is coupling: every module can read every table, and schema changes affect everyone.
Scale out by running identical copies
Because every copy can serve any request, adding capacity means adding copies behind a load balancer. That works as long as the copies keep no state of their own and the shared database keeps up.
Boundaries in code instead of on the network
Shopify chose to keep one deployable unit and enforce component boundaries with tools, getting much of the modularity of services without the operational cost of running many of them.

Timeline

  1. 2003

    DHH starts writing Basecamp as one application

  2. 2006

    Werner Vogels describes how Amazon grew out of its Obidos monolith into services

  3. 2014

    Lewis and Fowler’s “Microservices” article uses the monolith as its contrast

  4. 2015

    Fowler’s “MonolithFirst”: start with a monolith, split later

  5. 2016

    DHH’s “The Majestic Monolith”; Shopify decides its monolith needs boundaries

  6. 2019

    Shopify describes its modular monolith (“Deconstructing the Monolith”)

  7. 2023

    Prime Video cuts one service’s cost by over 90% by moving it into a single process

Sources8

Improve this page on GitHub