Monolith or microservices? A sober weighing
Updated: 2026-09
A monolith is simpler to build, test and operate. Microservices allow independent scaling and team work but cost substantial operational complexity. For almost every fresh start the monolith is the right choice — microservices solve a problem you must first have.
This architectural question is often asked too early and for the wrong reasons. Microservices have a reputation for being modern and scalable, and are therefore chosen before the problem they solve exists.
The decisive point: microservices are primarily an answer to an organisational problem, not a technical one. They let several teams deliver independently. Where that problem does not exist, you pay the cost without the benefit.
Head to head
| Criterion | Monolith | Microservices |
|---|---|---|
| Initial complexity | Low, one project | High, a distributed system from day one |
| Operations | One deployment, manageable monitoring | Many services, network, distributed debugging |
| Scaling | Scales as a whole | Individual parts scale independently |
| Team organisation | One team works well, many collide | Several teams deliver independently |
| Debugging | One flow, directly traceable | Distributed, barely possible without tracing |
| Changing boundaries | Boundaries easily moved | Wrongly drawn boundaries are expensive |
When Monolith wins
- —One team working together on one product.
- —The domain boundaries are not yet clear and will move.
- —Speed and operational simplicity matter more than independent scaling.
When Microservices wins
- —Several teams are blocking each other on delivery.
- —Individual parts have very different load profiles or requirements.
- —The domain boundaries are known from experience and stable.
Our take
Our view: start with a monolith, but with cleanly separated modules inside. That structure costs almost nothing extra and lets you extract individual parts later when a real reason appears. The reverse route — merging distributed services back together — is considerably more work.
The most common expensive mistake is drawing service boundaries before you know the domain well. Wrongly drawn boundaries produce services that must talk to each other constantly — the drawbacks of distribution without its benefits.
Parent service: Custom Software Engineering
Matching offers
Next.js web application at a fixed price
A bespoke web application on Next.js — fast, strong on SEO and maintainable, with a clearly bounded feature set and a binding fixed price. The result is a production-ready application without the usual cost surprises of open-ended hourly billing.
Multi-tenant SaaS architecture
This package lays the architectural foundation for scalable SaaS: strict tenant isolation, a clean roles and permissions model, and a structure that grows with you. The result is a base on which you can build features without security and scalability becoming a later construction site.
FAQ
Is a monolith not outdated?
No. A well-structured monolith is the superior choice for most applications. What is outdated is not the monolith but the unstructured monolith without internal boundaries.
When should we split?
When a concrete problem demands it: teams blocking each other, a part needing different scaling, or an area with different availability requirements. Not because it is time.
What is a modular monolith?
An application with clearly separated internal modules and defined interfaces between them, deployed together. It combines the simplicity of a monolith with the option to split later.