The Monolith is a software architecture in which an entire application runs as a single deployable unit — one process, one binary, one thing that works — and is therefore considered obsolete by everyone who has not yet spent two years replacing it with something worse.
The Monolith is the architecture that predates architecture. Before there were architecture committees, before there were 47-slide decks, before someone at Netflix mentioned the word “microservices” at a conference and twelve thousand CTOs reached simultaneously for their wallets, there was The Monolith. It booted. It served requests. It cost four hundred pounds a month. Nobody wrote blog posts about it, because writing a blog post about something that works is like writing a blog post about breathing.
Then someone stopped breathing on purpose, to see what would happen. What happened was Microservices.
“Your monolith is the best practice. For twelve hundred users, four CRUD operations, and a team of twelve. The simple system that works.”
— The Consultant, Interlude — The Blazer Years
The Redemption Arc
Every great hero follows the same trajectory: beloved, then abandoned, then missed, then restored. The Monolith is the Odysseus of software architecture — gone for twenty years while suitors (service meshes, API gateways, event buses) ransacked the house, and returning to find everything exactly as broken as you’d expect.
The story always begins the same way:
-
The Monolith works. Response time: 47 milliseconds. CPU utilization: 3%. Monthly cost: £400. The Grafana dashboard is green. Nobody is excited about this.
-
Someone attends a conference. Netflix is mentioned. Spotify is mentioned. The word “scale” is used without any reference to actual traffic numbers. The CTO returns with a vision. The vision has forty-seven boxes connected by lines.
-
The Monolith is replaced. Eighteen months. Two million pounds. Forty-seven Microservices. A service mesh. Three Kubernetes clusters. Redis (for caching queries that returned in twelve milliseconds). Response time: 2,300 milliseconds. Monthly cost: £47,000. The Grafana dashboard looks like a Christmas tree — red and blinking.
-
A consultant arrives. He asks one question: “What worked before this?” He asks to turn on the old monolith. They find it on a server nobody decommissioned. It boots in nine seconds. It responds in 47 milliseconds. The room falls silent.
-
The Monolith is restored. They call it “Consolidated Service Architecture” because the CTO cannot go to the board and say “we’re going back to the monolith.” The dashboard turns green. The AWS bill drops by a factor of 117.5. The consultant draws a small lizard on the whiteboard. Nobody knows why. But it works.
“Keep the monolith. Delete the rest.”
— The Consultant, Interlude — The Blazer Years
The Numbers
The Monolith’s case does not require rhetoric. It requires a table.
Monolith Microservices
Response time: 47ms 2,300ms
Monthly AWS bill: £400 £47,000
Boot time: 9 seconds "it's complicated"
Number of services: 1 47
Number of Grafana alerts: 0 Christmas tree
Redis savings (average): N/A 0.8ms (on 7% of queries)
Service mesh latency added: N/A 400ms
Architecture committee duration: 0 18 months
Time to draw working solution: 3 seconds see above
The Monolith is 49 times faster. 117.5 times cheaper. It requires no architecture committee, no service mesh, no discovery phase, and no consultant — although in the canonical case, it did eventually require a consultant to recommend going back to it, which is the most expensive way to arrive at the place you started.
The Canonical Monolith
The most thoroughly documented Monolith in the lifelog served twelve hundred users in London, 2019. It was a Java application. Ancient. Unsexy. It checked account balances. It did this in 47 milliseconds, on one server, for four hundred pounds a month.
The CTO called it “legacy.” The architecture committee called it “technical debt.” The enterprise architect called it “not containerized.” The consultant, who arrived later, called it “the thing that works.”
“We had a monolith. Java. Ancient. Couldn’t scale.”
“Did it work?”
— CTO and Consultant, Interlude — The Blazer Years
The word “couldn’t” is important. The monolith could scale. It was at 3% CPU. It had 97% of its capacity unused. It couldn’t scale in the way that a person sitting in an empty restaurant “can’t get a table” — the statement is technically parseable but describes no reality that anyone has observed.
The monolith was replaced anyway. Because it was boring. Because it was old. Because it wasn’t exciting enough to present at a conference. Because the CTO needed a slide deck, and “it works” is not a slide.
One Repo. One Binary. Cobra Subcommands.
The Monolith’s redemption is not merely historical. It is ongoing.
When V3 fought windmills — reactive signals, component namespacing, framework gymnastics at 1:47 AM — The Lizard climbed to the top of screen 9 and spoke:
“V4 rises from these learnings. Clean. Boring. Solid.
One repo. One binary. Cobra subcommands.”
— The V3 Saga Final Chapter - Is It Fun To Fight Windmills
One repo. Not a constellation of repositories with their own CI/CD pipelines and version matrices. One binary. Not a Docker container orchestrated by Kubernetes managed by Helm configured by YAML. Cobra subcommands. Not forty-seven microservices communicating over a network that can fail in ways that function calls in the same process cannot.
The manifesto carved it in stone:
THE BEST INTERFACE IS NO INTERFACE
THE BEST DATABASE IS ONE FILE
THE BEST DEPLOYMENT IS ONE BINARY
— The Lifelog Manifesto, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
One binary is The Monolith reduced to its purest form. Not a Java WAR file on a neglected server. Not even a running service. Just a file. Copy it. Run it. Done. No Docker. No container orchestration. No Kubernetes. The deployment is scp and the restart is systemctl and the monitoring is /health and the architecture committee is a developer and a lizard who agree on everything.
“No Docker. No container orchestration. No Kubernetes. One binary. Copy it. Run it. Done.”
— riclib, The Databases We Didn’t Build
The Three Keyboards
The Monolith has a darker origin story. Before it was a philosophy, it was a survival mechanism.
A beige Dell keyboard in a Lisbon office. Late at night. Fifteen global singletons. Circular dependencies so deep the refactor plan would eventually run to seven phases. A developer who built a monolith so tangled that the keyboard itself bore witness:
“I’ve never seen one build a monolith this tangled and still come back the next night.”
— The Dell, The Three Keyboards
This is the monolith before enlightenment — the monolith as accretion, as late-night solitude, as code that grows teeth. The Monolith is not inherently virtuous. It can be tangled. It can be a nightmare. But even at its worst, it is one nightmare, in one place, debuggable with one stack trace. The microservices replacement distributes the nightmare across forty-seven network boundaries and calls it “architecture.”
The Whiteboard Lizard
In every Monolith redemption story, The Lizard appears.
In London, 2019, a consultant drew a single box on a whiteboard. Labeled it “Monolith.” Then, without knowing why, drew a small lizard next to it. The drawing took three seconds. The architecture committee’s 47-slide deck had taken eighteen months. The three-second drawing conveyed everything the deck had failed to.
The cleaning staff asked if they should erase it. The consultant said to leave it.
Three weeks later, the microservices were erased. The monolith handled the twelve hundred users. The lizard stayed on the whiteboard. Someone photographed it and posted it to Slack with the caption: “The Gall’s Law Consultant drew this. Nobody knows why. But it worked.”
“He drew a small lizard next to the monolith box. He didn’t know why he drew it. It just felt right.”
— Interlude — The Blazer Years
The Lizard appears next to monoliths because the Lizard is the monolith principle — one organism, fully integrated, no microservices, no distributed coordination, no service mesh. The lizard brain does not decompose decisions into forty-seven independently deployable thought-services. The lizard brain decides. The lizard brain acts. The lizard brain responds in 47 milliseconds.
Why Nobody Wants It
The Monolith’s tragedy is not technical. It is social.
The Monolith cannot be presented at a conference. “We have one application and it works” is not a talk. It is not even a lightning talk. It is a sentence, and the sentence takes four seconds to say, and the conference slot is forty-five minutes, and nobody is paying a speaker fee for four seconds of advice.
The Monolith does not generate architecture committees. It does not require tribes. It does not produce 47-slide decks. It does not justify a VP of Platform Engineering. It does not create a career path for the enterprise architect who spent two years learning Kubernetes. The Monolith is a threat to the organizational complexity that many careers depend upon.
The Monolith is boring. And Boring Technology is, by definition, the thing that works while everyone else is still configuring the thing that doesn’t.
“I can’t go to the board and say we’re going back to the monolith.”
“Then call it something else.”
— CTO and Consultant, Interlude — The Blazer Years
The 488-Byte Monolith
The smallest documented monolith was 488 bytes. A bootblock on an Amiga 500, written in 1990 by a boy in Lisbon who had no choice but to make everything fit. Six layers of parallax stars. Copper list tricks. Hardware register hijacking. One binary — not by philosophy but by physics. There was nothing else. There was no Docker because Docker didn’t exist. There was no Kubernetes because the concept of orchestrating containers would not be invented for twenty-three years. There was one chip, one coprocessor, and the understanding that every byte wasted was a byte unavailable for stars.
“The best deployment is one binary.”
= 488 bytes. Everything included. Boot and run.
— 488 Bytes, or Why I Am As I Am
The boy grew up. Got gigabytes. Still builds monoliths. Not because he has to. Because he learned, at sixteen, that the thing that fits in one place is the thing that works, and the thing that works is the thing you ship, and the thing you ship is the thing that lets you sleep without a PagerDuty alert at 3 AM because Redis decided to reorganize its keys.
The Litmus Test
When confronted with a proposal to replace The Monolith, the practitioner is advised to check two numbers:
- Response time of the current monolith. (If it’s 47 milliseconds, stop reading.)
- Number of users. (If it’s less than 100,000, close the laptop.)
Then ask the question that no architecture committee has ever survived:
“What worked before this?”
If the answer is a monolith that booted in nine seconds and responded in 47 milliseconds and cost four hundred pounds a month and sat at 3% CPU utilization — then the answer is still the monolith. It was always the monolith. The monolith was the answer before the question was asked, and it will be the answer after the microservices are deleted and the Grafana dashboard turns green and the consultant draws a lizard on the whiteboard and walks out.
The Monolith is not legacy. The Monolith is not technical debt. The Monolith is not the thing you replace.
The Monolith is the thing you come back to.
