What are microservices and why they emerged
Published on 2026-09-12 by frfrand
No nacieron por una razón técnica sino organizativa. Qué problema resuelven de verdad, qué costos traen y por qué el monolito modular es la respuesta correcta para la mayoría.
A microservice is a small, independently deployable service responsible for a business capability, which communicates with the others over the network.
That is the definition. What is interesting is where the idea came from, because it explains when it makes sense.
It did not arise for a technical reason
The companies that popularized this approach did not have a performance problem. They had an organizational problem.
When two hundred people work on the same code and the same deployment, a bottleneck appears that is not technical: every change has to be coordinated, every release affects everyone, and everyone's speed is limited by the slowest team.
Microservices address that: if each team has its own service, its own database, and its own deployment, each one moves at its own pace.
From there comes the most useful rule for deciding: if your entire application is handled by a single team, you are paying the costs without receiving the main benefit.
What they do contribute technically
Scaling by parts. If image processing consumes a lot and the rest does not, you scale only that part. In a monolith you scale everything together.
Isolating failures. A service that goes down does not have to take the rest with it, if the system is designed to tolerate it. Without that part, you actually multiplied the failure points.
Different technologies. An intensive computation service in a compiled language, the rest in another. Useful sometimes, and a huge source of complexity if abused.
What they cost, from day one
It's worth being very honest here, because these costs appear even in small systems.
The network between each call. What was a function call becomes an HTTP request: latency, serialization, and the possibility of failure. All the retry, timeout, and circuit breaker code that didn't exist before is now yours.
Transactions. In one database, wrapping several operations in a transaction is trivial. Spread across three services with three databases, that disappears. You have to implement eventual consistency and compensations, which is much harder than it sounds.
Debugging. An error that spans five services is in five different logs. Without distributed tracing (which you have to set up and maintain), reconstructing what happened is very costly.
Operations. Ten services means ten deployments, ten configurations, ten sets of metrics and alerts.
The modular monolith
Between the two extremes there is an option that is often the right one and is rarely mentioned: a well-modularized monolith.
A single deployment, a single database, and inside, modules with clear boundaries: each with its own interface, without accessing other modules' tables behind the scenes.
It gives you almost all the organizational benefits of code without any of the network costs. And if one day a module truly needs to separate, the boundary is already drawn, so extracting it is feasible.
The path that works is this: start with a modular monolith, and extract a service when a concrete and measurable reason appears. Not the other way around.
The question that orders the decision
It is not "which architecture is better?", but "what is my real bottleneck?".
If several teams are stepping on each other when deploying, microservices solve it.
If a query lacks an index, or cache is missing, or the server is just short on memory, microservices solve nothing and add permanent work.