Monolith or microservices?

Few technical choices have become as loaded as monolith versus microservices. In many circles, microservices have been seen as the modern, obvious choice – and the monolith as something you apologize for. The reality is more sober. For most organizations, a well-built monolith isn’t just sufficient, it’s the smarter choice. Here’s the decision de-dramatized, without architecture fashion.

What the difference actually means

A monolith is a system that’s built, tested, and deployed as one unit. All the code lives in the same build. That makes it easy to understand, run locally, and debug – everything is in one place.

Microservices instead split the system into many small, independent services that run separately and communicate over the network. Each service can be developed, deployed, and scaled independently. That sounds liberating, and for the right organization it is. But independence has a price that’s rarely mentioned in the enthusiasm.

The real price of microservices

When microservices get pitched, it’s about scalability, independent teams, and technical freedom. What gets left out is the operations bill, and it’s substantial.

• Operations and monitoring. Every service needs its own deployment, logging, and monitoring. Ten services means ten things that can break separately, in the middle of the night.
• The network as a source of failure. Calls that are just a function call in a monolith now become network traffic that can be slow, fail, or arrive out of order.
• Team coordination. This is the biggest and most underestimated cost. Multiple services and teams have to keep their interfaces and versions aligned. What used to be a conversation across a desk becomes a contract between systems.

The point isn’t that this is impossible to manage – large organizations do it every day. The point is that it’s real work and real complexity, and that cost should be justified by an actual need, not by the architecture being fashionable.

The modern recommendation: modular monolith first

The pendulum has swung back, and the advice from experienced people is clear today: start with a modular monolith, and break out services when the organization requires it.

A modular monolith gives you the best of both worlds to start with. You build clear internal modules with clean boundaries – the same order and separation that microservices promise – but deploy everything as one unit and skip the network between the parts. If a module later needs to stand on its own, it can be broken out, precisely because the boundaries are already drawn.

The scaling myth

The strongest argument for microservices is scaling – and also the most misunderstood one. The truth is that the vast majority of systems never reach the traffic that would justify the split.

A concrete example: a company built twelve microservices from the start “to be able to scale,” for a product that hadn’t even launched yet. They spent months on infrastructure and coordination instead of features – and when the traffic did arrive, a single monolith would have handled it without blinking. A monolith, after all, scales a long way simply by running multiple copies behind a load balancer.

When microservices actually is the right choice

This doesn’t mean microservices are wrong – just that they solve an organizational problem more often than a technical one. The real payoff comes when you have many teams that need to work and deploy independently of each other without stepping on each other’s code. Then it’s worth the price of splitting up the system, because the alternative is everyone waiting on everyone else.

Other genuine reasons are parts with completely different needs – a heavy computation that has to scale on its own, or a component with requirements that shouldn’t bleed into the rest. The point is that the decision should be driven by a need you actually have, not an imagined future. And since a modular monolith can be broken up later, you rarely lose anything by waiting until the need is real.

Let the problem choose the architecture

The sober position is that architecture is a means, not an end. Ask what problem you’re trying to solve before you choose a form. If the answer is “we might need to scale one day,” a well-structured monolith is plenty. If the answer is “five teams trip over each other daily,” the split can be worth the effort.

The right architecture is the one that fits your organization and your actual load, not the one that looks most modern on an architecture diagram. If you’d like a neutral set of eyes on what your system actually needs, we at Weapp are glad to talk through the architecture and can walk through the choices with you before you build.