The wrong question
'Monolith or microservices?' is usually framed as though one option were the modern one and the other the old one. It is not like that. They are two ways of distributing complexity: the monolith concentrates it in the code; microservices move it to the network, the deployment and the operation.
The useful question is a different one: what complexity can this organisation take on, and where does it want it?
A spectrum, not two options
Between the extremes there are intermediate options that are often the best answer:
- Modular monolith: a single deployable application, but with separate modules and clear boundaries inside the code. It is easy to operate and allows you to split out later whatever needs splitting.
- Services per domain: a few large services, one per business area, instead of dozens of small ones.
The criteria that move the needle
Towards microservices push:
- Independent teams that need to deploy without coordinating.
- Parts of the system with very different scaling needs.
- Availability requirements per component (so that one failure does not bring everything down).
Towards a monolith push:
- A small team.
- A domain that is still changing a lot and whose boundaries are not clear.
- Limited operational capacity: without mature automation, many services mean many problems.
What each option demands
Microservices are not paid for in code alone. They demand components a monolith does not need:
| Component | Monolith | Microservices |
|---|---|---|
| Automated deployment | Advisable | Essential, per service |
| API gateway | Optional | Required |
| Asynchronous communication (queues, events) | Occasional | Routine |
| Distributed tracing | Optional | Essential for debugging |
| Identity management between services | Simple | Required and more complex |
| Data | One shared database | One per service, with its synchronisation |
Every row is infrastructure and operational cost. That is why the decision is written down (with its decision record) and revisited when the criteria change, not when the fashion changes.
How we apply it: Cloud Architecture.