Monolith

For a long time this shape had no name. Software was written as one piece and shipped as one piece, so there was no second arrangement to distinguish it from and no reason to give it a label. The name arrived only after an alternative did. Once microservices — cutting a system into features and deploying each one separately — started spreading, people needed a word for the original arrangement.

While the word was missing, architecture discussions went in circles. One person would say the current structure wasn't going to hold, and someone else would ask what the current structure even was. The first person meant that everything deploys as a single unit. The second heard that the code was a mess. Those are two different claims with two different fixes, and they were traveling under the same phrase.

What the word does is cut that confusion. It describes the number of deployment units and says nothing about code quality. Once the distinction had a name, "let's change the architecture" could be separated into "let's split the deployment unit" and "let's clean up the code," which are different projects with different costs.

One unit means four things are bundled together.

1. The code lives in one place. Billing, notifications, and document storage are folders inside the same project.
2. There is one build. A build turns written code into something runnable, and changing one line in notifications rebuilds billing along with everything else.
3. There is one running process. A single program runs on the server and every feature lives inside it.
4. There is one database. The documents table and the payments table sit in the same place, so a single query can read across both.

Where that bundling pays off, it pays off in communication cost, which is effectively zero. If notifications need to know something about a document, the code just calls a function. In a split system the same call becomes a network request, and someone has to decide what happens when that request fails.

Where it costs, it costs in the same place. Because deployment is one unit, fixing a notification string also ships billing. What has to be checked before a release becomes the whole system rather than the part that changed, and a problem found in one team's work rolls back the release another team was waiting on. Traffic concentrated on search still requires duplicating the entire application to add servers, which wastes capacity and limits scalability. A memory leak in one feature stops the whole process, which makes that process a single point of failure.

New products almost always start here. While what to build is still changing weekly, nobody knows where the boundaries between features actually fall, and cutting along a boundary you guessed at means redrawing it two months later. Inside one unit, redrawing a boundary is a matter of moving folders around; once the pieces deploy separately, it means merging two running services back into one.

Team size matters too. Up to roughly ten engineers the deployment queue stays short enough that one unit costs little. The signals that it has started to hurt are usually these three.

1. Build and test time stretches out. Three minutes becoming twenty-five cuts how many times a day you can ship, and every skipped release makes the next one bigger.
2. Deployments queue up. Three teams want to ship on the same day, and one team's failure holds all three.
3. Several teams edit the same files. Merges conflict constantly, and coupling — how entangled components are with each other — climbs until a change in notifications breaks billing.

At that point there are two ways out. Split the deployment unit and move toward microservices, or keep shipping one unit and divide only the inside into modules. The first requires a deployment path and a monitoring setup for every service, so somebody on the team has to own that work full time. The second raises cohesion — how tightly the code inside one module sticks to a single job — and removes most of the pain apart from the queue itself.

"Let's stay a monolith for now. We don't know where the boundaries are, and cutting first means gluing it back later."

The product is early enough that the cost of splitting isn't worth paying yet.

"It's not slow because it's a monolith. Releases are scary because there are no tests."

Correcting a diagnosis that blames the architecture for something the test suite is responsible for.

"We'll pull billing out and leave the rest as the monolith."

A plan to separate only the part causing trouble rather than breaking the whole system apart.

Pagedeck has twelve engineers among its forty-five people and still runs as one unit. Last quarter Theo brought a proposal to split it, and his evidence was that builds had grown to twenty-two minutes. What Mia asked back was how much of those twenty-two minutes was checking anything, and it turned out nearly half of it was old tests that returned the same answer every time.

After the cleanup the build took nine minutes and the split got pushed out a year. One piece did get pulled out: document conversion. While a conversion ran it consumed enough server memory to slow down unrelated requests. The case for changing an architecture is a symptom you can point at like that, not a sense that the company has gotten bigger.

The most common mistake is reading monolith as outdated. Microservices came later, so it's easy to assume the earlier thing was superseded. But these are a trade, not a timeline. One side pays the cost of splitting and gets independent deployment; the other declines the cost and ships together. Twelve engineers running twenty services spend the quarter building deployment pipelines and monitoring dashboards instead of building the features customers asked for.

The second is using the word for tangled code. Plenty of old monoliths genuinely are tangled, so the two ideas arrive together. The word only describes the deployment unit, though. There are monoliths divided cleanly into modules that call each other through defined entry points, and there are microservices that reach straight into each other's databases. Collapsing the two leads to the wrong fix: if tangled code is the problem and you split the deployment instead, the tangle is now spread across a network and the cause is harder to find.