When a Monolith Is the Correct Answer

“Monolith” has become a slur in a great deal of architecture conversation, shorthand for legacy, unscalable, poorly engineered — and a genuinely large share of new projects reach for microservices by default specifically to avoid being associated with the word, regardless of whether the project’s actual shape justifies the added complexity.

I’ve written about the real cost of a distributed monolith, and about the questions worth asking before adopting Kubernetes. This is the more fundamental version of both arguments: a monolith is not a mistake by default. For a genuine share of real systems, it’s the architecturally correct answer, and treating it as an embarrassment to graduate away from as quickly as possible produces exactly the premature complexity both of those other pieces warn against.

What a monolith genuinely optimises for

A well-built monolith — a single, coherent codebase and deployment unit, internally well-organised with clear module boundaries — offers genuine advantages a distributed system structurally cannot match: a single deployment to reason about, no network calls between components that used to be simple function calls, transactional consistency across the whole system without the distributed-transaction complexity microservices introduce, and a debugging experience where a stack trace tells the whole story rather than requiring correlation across multiple services’ separate logs.

Where these advantages genuinely outweigh microservices’ benefits

A small-to-medium team, without the operational capacity microservices genuinely require. Microservices’ benefits — independent deployability, fault isolation, technology diversity per service — come with a real operational tax: more infrastructure to manage, more deployment pipelines, more monitoring surface. A small team paying that tax without a genuine corresponding need is paying pure overhead, the same over-engineering pattern I’ve written about for Kubernetes adoption specifically.

A system without genuinely independent scaling needs across its components. Microservices earn their complexity when different parts of a system genuinely need to scale independently — a specific bottleneck component handling disproportionate load. A system where load is roughly uniform across its logical components gets none of that scaling benefit from splitting into services, and pays the coordination cost anyway.

A domain that hasn’t yet stabilised enough to draw confident service boundaries. Splitting a system into services requires knowing, with real confidence, where the genuine domain boundaries sit — connecting directly to the distributed-monolith failure mode I’ve written about, where boundaries drawn along convenient but ultimately wrong lines produce all of microservices’ cost with none of its benefit. A genuinely young, still-evolving domain is frequently better served by a well-organised monolith that can be split later, once the boundaries have actually revealed themselves through real usage, than by a premature split along boundaries nobody yet has enough evidence to draw confidently.

Why the reputational pressure runs the wrong direction

Choosing microservices photographs better in a hiring conversation and a conference talk than choosing a monolith does, which creates a genuine, non-technical pressure toward the more complex architecture regardless of whether the system’s actual shape justifies it — the same dynamic I’ve written about for big-bang migrations getting chosen because they tell a better story, not because they’re the right fit. A monolith, chosen deliberately after genuinely weighing the trade-offs, is not an embarrassing admission of limited ambition. It’s frequently the more disciplined, more honest engineering decision, and the willingness to make it despite the reputational pressure against it is itself a signal of genuine technical judgment.

What one deliberate choice actually delivered

A three-person engineering team building a new internal operations tool considered microservices early, largely because the founding engineer had built microservices at a previous, much larger company and defaulted to the familiar pattern. A deliberate review against the team’s actual size, the system’s genuinely uniform load profile, and the still-evolving domain boundaries led to a considered decision to build a well-organised monolith instead — clear internal module boundaries, a single deployment, and none of the coordination overhead three people would have struggled to sustain across several independently deployed services. Eighteen months later, with the domain considerably better understood, one genuinely independent-scaling component was extracted into its own service — the boundary the original monolith’s internal organisation had made straightforward to identify and split cleanly, exactly when the evidence for that specific split actually existed.

Assessing whether a specific system’s actual shape genuinely justifies microservices’ complexity, or would be better served by a well-organised monolith, is exactly the kind of architecture judgment a technology control assessment is built to make explicit.

The team’s original instinct wasn’t wrong because microservices are bad — it was wrong because the decision was being made from familiarity rather than from the specific system’s actual, current shape.

If the answer eventually points toward splitting, the pattern chosen matters — see strangler fig, big bang, and parallel run.

The extraction eighteen months later succeeded cleanly precisely because the monolith’s internal organisation had kept the eventual boundary legible the whole time — a genuine benefit of building it well from the start, not just building it small.