What is a monolith?
A monolith is a system built, tested, and deployed as a single unified unit, where all the code lives in the same build. It's neither good nor bad in itself – for one team, one product, and fast development, it's often the simplest and most effective choice. A modular monolith is the modern middle ground.
The word monolith has picked up an undeserved negative ring. It’s sometimes used as a slur for anything considered old and cumbersome, something you should have left behind. That picture is misleading. Here’s what a monolith actually is, and why it’s the right choice for many systems.
The definition, without judgment
A monolith is a system that’s built, tested, and deployed as a single unit. All the code – interface, business logic, database access – lives in the same build and ships together. When you update the system, you deploy the whole thing, not an individual part.
That’s the entire definition, and it carries no judgment. A monolith isn’t automatically messy or outdated, any more than a split-up system is automatically well built. The architecture describes how the system is packaged and run, not how well it’s written.
The myth that monolith means “ugly” usually comes from encounters with old systems that happen to be both monolithic and poorly structured. But the two things aren’t connected. A well-built monolith can be clean, clear, and easy to work in.
When the monolith is right
For a large share of systems, the monolith isn’t just acceptable, it’s the best choice. It particularly shines in three situations:
- One team. When the same group owns the whole system, there’s no need to split it up to let different teams work independently. Splitting solves a coordination problem you don’t have.
- One product. A unified system that does one clear thing does well staying together. The parts naturally belong together and benefit from living together.
- Fast development. Fewer moving parts means simpler operations, faster debugging, and less overhead. Early products need to move fast, and the monolith rarely gets in the way.
A monolith has everything in one place: one build to deploy, one log to read, one flow to follow when something goes wrong. It’s a strength that’s easy to underestimate until you’ve lost it.
A concrete scenario
Say a company is building a booking service. A team of five, one product, an early market. They choose to build it as a monolith: accounts, bookings, payments, and notifications in the same system.
The result is that they can spend almost all their time on features instead of infrastructure. A new developer gets to grips with one system, not ten. When a bug shows up, the whole flow is in one place to debug. Had they instead split everything into small services from day one, they’d have paid the operational and coordination cost of a problem – many independent teams – that they don’t yet have. Splitting too early is one of the most common and expensive architecture mistakes.
The modern middle ground: modular monolith
There’s a third option that’s become popular precisely because it takes the best of both worlds: the modular monolith is a single system in operation, but internally split into clearly bounded modules with clean interfaces between them – so you get order and structure without spreading the system across the network.
The point is to distinguish logical from physical splitting. You can have well-separated parts without every part becoming its own service with its own operations. That gives simple operations now and a clear line to cut along if the system ever genuinely needs to be broken up.
A common mistake is thinking a monolith can’t be well structured – that order requires splitting the system into services. That’s not true. Structure is a matter of how the code is organized internally, not how it’s packaged and deployed. A sloppy monolith and a sloppy collection of microservices are both messy; a well-thought-out modular monolith is orderly without paying the network price. Keeping the two questions separate saves many expensive decisions made on the wrong grounds.
How to think about the choice
Start from the organization and the product, not from what sounds most modern. If you have one team, one product, and a need for pace, a monolith – ideally modular – is usually right. Break out services only once an actual need, like many independent teams, forces it.
If you want a neutral opinion on what your particular system is best served by, at Weapp we’re glad to talk through the architecture together before you build.
Frequently asked questions
Is a monolith a bad thing?
No, that's a persistent myth. A monolith is simply a system that runs as one unit, and for many products it's the smartest choice. It's simpler to build, run, and debug than a scattered system. The reputation that monoliths are ugly usually comes from old, poorly structured systems – not from the architecture itself.
When is a monolith the right choice?
When you have one team, one product, and want to move fast. A monolith gives you few moving parts, simple operations, and fast debugging, which is exactly what early products and smaller organizations need. As long as complexity doesn't force a split, the unified solution is often both cheaper and more stable.
What's the difference from microservices?
A monolith runs as a single unit, while microservices split the system into many small services that release and scale independently. The monolith is simpler to build and run; microservices give you independent parts at the cost of significantly more operational and debugging complexity. The choice is more about organization and size than about what's fashionable.
What is a modular monolith?
A modular monolith is still a single system in operation, but internally split into clearly bounded modules with clean interfaces between them. You get the monolith's simple operations and the structural benefits otherwise associated with microservices, without the network complexity. For many, it's the best middle ground.
Can you move from a monolith to microservices later?
Yes, and that's often the smart order. Starting with a well-structured monolith and breaking out services only once a real need arises is less risky than splitting too early. A modular monolith makes that transition easier, since the modules already have clear boundaries to cut along.