The Distributed Monolith and the "Microservices = Better" Misconception
Objectives
By the end of the lesson, you can recognise the signs of a distributed monolith, and you can justify why an architecture is not better just because it consists of several services.
Why talk about this separately?
Microservices are fashionable, so they often appear as a synonym for an "advanced" architecture. This assumption — that more, smaller services connected over a network are always better than a monolith — is wrong. Distribution has a price (3.3), and if the benefits do not materialise, only the price remains.
What is a distributed monolith?
A distributed monolith is a system split into separate processes, whose parts nevertheless cannot meaningfully change or work separately. The services talk over the network, but the coupling remains: the system has both the drawbacks of the monolith (coupled releases) and those of distributed systems (network failures, latency). The term is common professional usage, not standardised; the matching signs in descriptions are:
Coordinated release: a change in one service forces changes in others.
Shared data: several services write the same data directly.
Long synchronous chains: one request passes through many services, and the failure of any of them stops everything.
Technical cut: the system was split by technical layers (front end, back end), not by business capabilities.
flowchart LR
K["Request"] --> A["Service A"]
A -->|"sync"| B["Service B"]
B -->|"sync"| C["Service C"]
C -->|"sync"| D["Service D"]
A --> DB[("Shared data")]
C --> DB
On the diagram, the failure domain did not become smaller: if D fails, the request fails. The network complexity appeared, the benefit did not.
Event sending does not automatically solve the coupling either: if every consumer expects the exact version of the same internal data structure, they have to be updated together with the events as well.
Why is microservices not "better"?
The benefit is conditional. It appears if the parts truly change at different paces, scale separately or require a separate failure boundary, and the team can manage automation, observability and operations.
The boundary is hard to fix. According to Fowler, most successful microservices systems started as monoliths and were split afterwards; systems built as microservices from scratch often ran into serious difficulties. The reason is that service boundaries are hard to set well in advance, and moving functions between services is much harder. Fowler himself notes that the evidence on this question is thin, so he offers it as cautious advice.
The premium is real. Because of the "microservice premium", the style does not pay off for most systems; according to Fowler most systems should stay monolithic with well-defined internal modules.
The organisation matters. The structure of the system copies the communication structure of the organisation (Conway, see 1.2): if a small team looks after many services, the effort of maintaining the infrastructure consumes the benefit of independence.
Situation
What does it indicate?
A change requires the coordinated release of three services
Distributed monolith
Small team, uncertain product boundaries, many services
The premium may exceed the benefit
Really separate life cycles, separately scaled parts, several teams
Microservices may be justified
Common misconceptions
Statement
Clarification
"Microservices are always better than a monolith."
Both are trade-offs; the requirements decide.
"If it runs in a separate process, it is already independent."
If it must be released and operated together, it is a distributed monolith.
"Event-driven communication eliminates coupling."
Dependence on the exact version of the data structure remains.
"The monolith is obsolete."
For many systems a well-modular monolith is the right choice.
In short
A distributed monolith runs in separate processes but changes and works together.
Its signs: coordinated release, shared data, long synchronous chains, technical cut.
The benefit of microservices is conditional, the price is real.
For most systems a well-modular monolith may be enough.
Review questions
Based on what signs would you call a system a distributed monolith?
Why does event sending alone not solve the coupling?
How would you argue that a concrete system should not be microservices?
The Distributed Monolith and the "Microservices = Better" Misconception
Objectives
By the end of the lesson, you can recognise the signs of a distributed monolith, and you can justify why an architecture is not better just because it consists of several services.
Why talk about this separately?
Microservices are fashionable, so they often appear as a synonym for an "advanced" architecture. This assumption — that more, smaller services connected over a network are always better than a monolith — is wrong. Distribution has a price (3.3), and if the benefits do not materialise, only the price remains.
What is a distributed monolith?
A distributed monolith is a system split into separate processes, whose parts nevertheless cannot meaningfully change or work separately. The services talk over the network, but the coupling remains: the system has both the drawbacks of the monolith (coupled releases) and those of distributed systems (network failures, latency). The term is common professional usage, not standardised; the matching signs in descriptions are:
flowchart LR K["Request"] --> A["Service A"] A -->|"sync"| B["Service B"] B -->|"sync"| C["Service C"] C -->|"sync"| D["Service D"] A --> DB[("Shared data")] C --> DBOn the diagram, the failure domain did not become smaller: if D fails, the request fails. The network complexity appeared, the benefit did not.
Event sending does not automatically solve the coupling either: if every consumer expects the exact version of the same internal data structure, they have to be updated together with the events as well.
Why is microservices not "better"?
Common misconceptions
In short
Review questions
Learning resources