Monolith or microservices: how to choose without regretting it
Published on 2026-09-12 by frfrand
Cinco preguntas que deciden mejor que cualquier diagrama, por qué la arquitectura correcta depende de tu equipo y no de tu tecnología, y cómo dejar la puerta abierta a cambiar.
The discussion about architecture usually starts with technology and ends badly. People choose what's trendy, or what a company with a thousand engineers uses, and then they fight with the consequences for years.
Five questions order the decision better, and none of them are technical.
1. How many teams deploy?
It's the most important question, because the central benefit of separating services is that different teams can publish without coordinating.
One team, one deployment. It's not a rigid rule, it's an observation of what works: the cost of coordinating deployments only exists if there are several teams coordinating.
2. What is actually slow?
You have to measure it, not assume it.
Most of the time, the bottleneck of a web application is an unindexed query, lack of caching, or a slow external call. None of those three is fixed by separating services; in fact, separating adds network latency on top.
If you never measured, architecture is not your problem yet.
3. Who operates it at three in the morning?
Complexity has a cost that is paid on call.
Ten services are ten things that can fail, ten sets of logs to correlate, and ten deployments to revert. If the team is small, that cost is paid by one person, and they pay it at night.
It's a legitimate consideration and it almost never appears in the diagrams.
4. Is there a part that scales differently?
If video processing consumes twenty times more than the rest and grows separately, there is a real argument for separating it.
The keyword is measured. "This will probably grow" is not enough: it almost never grows as expected.
5. Can it be undone?
The best architecture is the one that does not lock you in.
And here is an asymmetry worth knowing: extracting a service from a well-modularized monolith is work; putting distributed services back together is much worse.
That is why, when in doubt, the least risky path is to start together.
The order that works
Modular monolith first. One deployment, one base, and inside modules with clear boundaries: each one with its interface, without accessing other tables from behind.
That internal discipline is what makes everything else possible. A monolith without internal boundaries is indeed a problem, and it is what gave the word a bad reputation.
Measure where it hurts. With data, not intuition.
Extract one service, with a concrete reason. One. Not the entire system.
What is almost always the right answer
For a team of fewer than ten people: modular monolith, deployed automatically, with good logs and metrics.
That is not conservatism: it is that the main benefit of microservices (independence between teams) does not exist when there is only one team, and the costs exist anyway.
In ArduMaker this translates into something practical: you can have a monolith deployed from a repository, and the day you extract a service, deploy it on the same VPS or another, with tunnels between them instead of exposing them. The architecture can evolve without redoing the infrastructure.
