Microservices vs Monolith: When to Break Apart and When to Consolidate
A pragmatic framework for choosing between microservices and a monolith based on team size, deployment complexity and actual scaling needs — not industry hype.
Microservices became the default architectural advice for an entire generation of engineering teams, often regardless of whether the team or the problem actually warranted the complexity. The honest truth is that most companies adopting microservices are solving an organisational problem with a technical solution — and paying an operational tax for years afterward.
What microservices actually cost
Every service boundary you draw adds network calls where there used to be function calls, distributed tracing where there used to be a stack trace, and deployment coordination where there used to be a single build. For a small team, this overhead can consume more engineering time than the features the architecture was supposed to enable.
The team-size signal that actually matters
Microservices solve a specific problem: multiple teams needing to deploy independently without blocking each other. If you have one engineering team of under fifteen people, you almost certainly don't have the organisational scaling problem microservices were designed to solve — a well-structured modular monolith gives you most of the benefit with a fraction of the operational cost.
When breaking apart genuinely pays off
The clearest signal for extracting a service is when one component has fundamentally different scaling characteristics or deployment cadence than the rest of the system — a video processing pipeline that needs to scale independently of the main web application, for example, or a component multiple independent teams need to own and deploy on their own schedule.
Consolidating back to a monolith is not admitting failure
A growing number of engineering teams are consolidating over-decomposed microservices back into modular monoliths once they discover the operational overhead outweighs the benefit for their actual scale. This is a legitimate architectural decision, not a step backward — the goal was always to ship reliable software efficiently, not to have the most distributed architecture on the team's resume.
Frequently asked questions
How many engineers do you need before microservices make sense?
There's no universal number, but as a rule of thumb, if a single team can hold the whole system's architecture in their heads and deploy it without stepping on each other, you likely don't need microservices yet. The signal is organisational — multiple teams needing independent deploy cycles — not a headcount threshold.
Is a modular monolith harder to scale than microservices?
Not for most businesses — a well-structured monolith can scale vertically and horizontally (behind a load balancer, with read replicas) to handle significant traffic. Microservices solve a team-coordination problem more than a raw scaling problem, and a monolith with clear internal boundaries can be split later if it genuinely becomes necessary.
The WebSool take
We design architecture around your team's actual size and deployment needs, not the pattern that's trending. Whether that means a modular monolith or genuine microservices, we'll tell you honestly which one gets you to production faster and keeps you there.
