When to split a monolith: the questions matter more than the hype
Microservices are a popular answer to the scaling question. But the right question is not 'split or not' - it is 'why and when'.
The conversation about moving from a monolith to microservices has been running in technology teams for several years. For many engineers it sounds like the obvious next step. For many business owners it sounds like an expensive technical project with unclear returns.
Both sides are right in their own way. The problem is not that microservices are a bad idea. The problem is that the question "should we split the monolith?" is often asked before the question "why?"
What actually sells the idea of splitting
I usually hear a few arguments for making the move. They sound convincing, but each deserves scrutiny.
"We cannot scale." This often means that one part of the system is overloaded and the rest is not. A monolith cannot scale parts independently. That is a real problem - but it is solved by splitting only when the load genuinely does not fit on a single machine. Most companies never reach that limit.
"Releases block each other." Teams get in each other's way making changes. This is more of an organizational problem than an architectural one. Splitting into services can help, but only if responsibilities between teams are also split at the same time. Otherwise the same conflicts reappear in a different form.
"It's the right modern approach." That is not an argument. Netflix, Amazon, and Google built microservices because their monoliths could no longer handle the load and the number of teams. That is not the same argument for a company with fifty developers.
What actually gets harder after splitting
Distributed systems are more complex than a monolith. This is not an opinion - it is a fact.
- Debugging errors that occur at the boundary between services takes longer.
- Network calls between services add latency and failure points that do not exist in a monolith.
- Data management between services requires additional design work - who owns which data, how consistency is maintained.
- Deploying and monitoring ten services is more complex than one.
I am not saying this is insurmountable. I am saying it costs extra money and time that needs to be included in the plan.
Signs that splitting is genuinely needed
A few situations where the arguments in favour of splitting become concrete:
- there is one component that is overloaded and requires independent scaling, while everything else works fine;
- several independent teams are constantly in conflict over the codebase and delaying each other's releases - and the organisational responsibilities are already separated;
- one part of the system requires a different level of security or reliability than the rest;
- there is a component with a different technology stack that cannot be incorporated into the shared codebase.
If none of these points describes the current situation - the problem is most likely not the architecture.
Questions before making the decision
- What specific problem makes the current architecture insufficient?
- If we split - how will that specific problem change, and how will we measure the improvement?
- Who will own each service - a specific team with clear accountability?
- Is the infrastructure and expertise in place to operate a distributed system?
- What is the plan for the transition period - how to keep developing the product while splitting?
Good architecture is not fashionable architecture. It is architecture that solves the current problem at an acceptable cost of maintenance.