Microservices or a modular monolith? A decision about team size
Choosing between microservices and a modular monolith is not a technical decision but an organisational one. The criteria we apply on enterprise work.
The common question in a first architecture workshop is: microservices or a monolith? Our answer almost always starts with another question — how many independent teams will work on this system?
The hidden cost of microservices
Microservices solve team independence, not performance. With a single team of seven, network boundaries between services only add cost: distributed tracing, eventually consistent transactions and a harder deployment story.
Our criteria
- More than three independent teams on different release cycles
- Parts of the system that must scale at very different ratios
- A regulatory requirement to isolate data
If none of the three holds, a modular monolith with clear in-process boundaries is the better call.
The modular monolith in practice
We enforce boundaries with independent modules and one rule: no module reads another module's tables. If a split is ever needed, each module is already ready to leave.
