Microservices vs monolith: when splitting is actually justified
Why moving to microservices is not automatically the right decision, and how to tell whether your team and system are ready for the complexity it brings.
Microservices have been one of the most actively discussed architecture topics for the past few years. Netflix, Amazon, Uber - the companies everyone cites when talking about the benefits of the approach. And more and more I hear from executives: "We need to move to microservices."
My first question is always: why. Not because microservices work poorly. But because this decision has a real cost that is easy to underestimate.
What problem they actually solve
Microservice architecture emerged as a response to a specific problem at large companies: when hundreds of developers work on the same system, monolithic code becomes a bottleneck. Different teams get in each other's way during deploys, builds take hours, a single bug in one module blocks the entire release.
That is a real problem. But it is a problem that shows up at a specific scale.
If you have three developers and one monolithic service, the problem is not the architecture. If you have twenty developers and well-structured code, probably not either. Moving to microservices "because that's what large companies do" is copying a solution without copying the context in which it appeared.
What you get along with microservices
Along with independent deployment of individual services and the ability to scale them separately, you get:
- a complex network topology that needs to be maintained and debugged;
- the need for orchestration - Kubernetes and all the accompanying infrastructure;
- distributed transactions and all the complexity that comes with them;
- multiplied monitoring and logging tasks: instead of one application, dozens of services;
- new categories of failure: network latency between services, partial failures, cascade failures.
Every item on that list is not abstract complexity - it is real operational load on the team. Netflix and Amazon carry that load because they have thousands of engineers and dedicated infrastructure teams.
When splitting is justified
Breaking into services makes sense in a few situations:
When different parts of the system have fundamentally different scaling requirements. If image processing consumes thousands of times more resources than user profile management, that is a genuine candidate for extraction.
When different parts are developed by independent teams with different release cadences. Separation removes organisational friction in this case.
When you need different technology stacks for different tasks, and mixing them in one process is impossible or expensive.
What is not sufficient justification: wanting to "do what Netflix does", following fashion, or assuming that microservices will automatically make the system scalable.
The more honest question
Before the microservices conversation, I recommend answering more grounded questions:
- What is the actual problem we are solving - slow deploys, team coordination, scaling under load?
- Do we have a team with experience operating distributed systems?
- Do we have a mature monitoring and observability practice?
- How clearly are the boundaries between parts of our system defined - can we split them cleanly?
- Are we prepared for the first six months after the switch being spent on infrastructure more than on the product?
A well-structured monolith with clean module boundaries is often better than poorly-cut microservices. The right question is not "monolith or microservices" but "which architecture fits our scale and our team right now".