Why we usually start with a modular monolith
For most systems, a modular monolith is the more economical choice — until a concrete boundary genuinely calls for distributed services.
What is this? · Perspective
A reasoned position — with a thesis, the trade-offs and the case in which we would decide differently. Not a neutral overview, but a stance. Go to overview
What this is about.
Microservices are often treated as the default for serious software. In practice, many teams pay the costs of distributed systems — network boundaries, eventual consistency, operational overhead — before they need the benefits. We have watched this happen for years and deliberately decide against it as long as nothing argues in its favor.
Why we see it this way.
Complexity should follow necessity
A modular monolith allows clear module boundaries within a single codebase and a single deployment. The boundaries are explicit, but crossing them doesn't cost a network hop.
Changes stay local
A change that spans several modules is one commit and one deployment — not a coordinated rollout across several services with versioned contracts.
Operations are simpler
One deployment, one log stream, one transaction. Much of the tooling and discipline that distributed systems demand simply isn't needed here.
The decision stays open
Cleanly cut modules can be extracted selectively later. A modular monolith doesn't rule out microservices — it defers the decision until it can be made on solid ground.
What it costs.
Without module discipline, a monolith can turn into a big ball of mud. The pattern doesn't protect against bad boundaries — it only makes them cheaper to fix.
Individual parts can't be scaled independently; the service scales as a whole.
Very large teams that must ship completely independently run into the limits of a shared codebase.
When we would decide differently.
When parts of a system have radically different scaling or availability requirements.
When several teams demonstrably need to ship independently and coordination inside the monolith becomes more expensive than distributed boundaries.
When a domain boundary is so stable and clear that distributing it measurably delivers more than it costs.
Where we stand.
We don't favor the modular monolith on principle, but because it keeps the expensive decisions open. Distributed systems are a tool for concrete problems — not the starting point.
Related topics.
Guides, decisions, services and case studies connected to this page.
Architecture decisions
Playbooks
See it differently? Let's talk.
Perspectives are there to be challenged. If you see it differently — or have a concrete problem — talk to our management.
