Microservices: When to Split and When to Wait—Avoiding the Common Traps
Last year, a startup CTO took me out for dinner. He looked stressed. “We’re about to split our monolith into microservices,” he said. “The CEO thinks it’s the ‘modern’ way. But something feels off.”
I asked: “How big is your team?”
“Six backend engineers.”
“How many users?”
“About twenty thousand.”
“How often do you deploy?”
“Every two weeks. It’s stable.”
I put down my chopsticks. “If you split now, you’re digging a hole you don’t need.”
He looked confused. “But isn’t microservices the future?”
This is the trap. People treat microservices as a status symbol. The reality is often the opposite: splitting wrong hurts more than not splitting at all.
01 Microservices Are a Scalpel, Not a Hammer
Let’s be clear: microservices aren’t the goal. Solving the problems of your monolith is the goal.
What problems does a monolith have? Slow deployments, changes that ripple everywhere, teams stepping on each other, one module failing bringing down everything. If you don’t have these problems, why split?
Microservices are a scalpel. A hammer sees every problem as a nail. A scalpel is used only when needed.
Counter‑intuitive truth: Most teams never reach the point where microservices make sense. If you have fewer than ten engineers, splitting will probably drown you in operations work.
02 When Should You Actually Split?
Look for three signals. If you have at least two, consider splitting.
Signal 1: The team has grown and Git conflicts are constant
When every pull request takes half a day to merge because three people touched the same file, your team has outgrown a single codebase. Splitting here frees the team to move independently.
Signal 2: Deployment frequency is held back by the monolith
You want to ship a small change to one module, but you have to wait for everyone else’s tests to finish. You used to deploy three times a day; now it’s once a week. Splitting here lets teams deploy independently.
Signal 3: Module boundaries are already clear
You can draw a diagram of “orders” vs “users” in your sleep. The dependencies are obvious and stable. Splitting here is natural—you’re just pulling apart something already separated in your head.
If none of these signals exist, you’re probably splitting for the wrong reasons.
03 When Should You Absolutely Not Split?
Knowing when not to split is more important.
Case 1: Team size under ten engineers
The biggest cost of microservices isn’t code—it’s operations. Each service needs monitoring, logging, CI/CD, service discovery. With ten people, splitting into five services triples your operations load. Who writes business code?
Case 2: Business is still in experimentation mode
If you’re still figuring out product‑market fit, your domain boundaries will change next quarter. The service you split today will need to be redrawn tomorrow. Let the monolith absorb the chaos until things stabilize.
Case 3: Strong data consistency is required
Microservices hate distributed transactions. If your business requires strict consistency (finance, inventory, accounts), splitting makes everything harder. You’ll need sagas, compensating transactions, eventual consistency—complexity that can kill your velocity.
Case 4: No one on the team has done microservices before
A greenfield project where everyone is learning microservices for the first time is a recipe for pain. Start with a well‑modularized monolith, then split gradually. You can always split later. You can’t un‑split easily if you do it wrong.
04 The Real Costs No One Talks About
People love to list the benefits. They rarely calculate the costs.
Cost 1: Network latency
What was a function call now becomes an RPC. What took 50ms can now take 500ms. If you have call chains, latency multiplies.
Cost 2: Distributed transactions
ACID transactions were simple. Now you need sagas, TCC, or eventual consistency. Code complexity doubles. Debugging becomes a nightmare. When data gets out of sync, you’ll wish you never touched the monolith.
Cost 3: Operational complexity
You used to monitor one app. Now you monitor fifteen. Logs are scattered. Debugging a single request means hunting across six services. Deployment used to be one job; now you have to coordinate ordering between teams.
Cost 4: Debugging hell
On your laptop, you could run one service and set breakpoints. Now you need to run fifteen services locally—good luck with memory. Production issues become expeditions through distributed traces.
An e‑commerce company spent two years splitting into microservices. Their ops lead told me: “With the monolith, three people ran the system. Now fifteen people run dozens of services, and incidents haven’t dropped.”
05 How to Define Boundaries—Get It Wrong and You’re Worse Off
If you decide to split, the most critical question is: where do you draw the lines?
The principle: split by business capability, not technical layer.
Orders, users, inventory, payments—these are business boundaries.
Frontend, backend, database—these are technical layers. Splitting by technical layer doesn’t solve anything.
The symptom of wrong boundaries: one business change requires touching three services. You’ve created “distributed monolith”—all the complexity of microservices with none of the independence.
A company split “orders” and “shipping” into separate services. Every deployment needed both services to change together. They gained nothing—just added network calls and transaction headaches. Eventually they merged them back.
The purpose of splitting is to isolate change, not spread it. If a change now touches more code than before, you’ve drawn the boundaries wrong.
06 A Real Story: Two Years of Splitting, Then Merging Back
A SaaS company decided to go all‑in on microservices. The CEO heard it was the future. The tech lead thought it would prepare them for scale.
Two years later:
One service became eighteen
Ops team grew from two to six
Deployments required coordinating five services, often pushing to midnight
Mean time to recovery went from 20 minutes to over two hours—logs were scattered across systems
The CEO asked when the migration would finish. No one could answer.
Eventually, they merged services that frequently changed together back into larger components. Service count dropped to eight. Ops stress halved. Deployment speed improved.
The tech lead told me afterward: “The biggest lesson wasn’t how to split. It was learning that we didn’t need to split in the first place.”
The Bottom Line
Microservices are powerful. But they’re not free. Before you split, ask yourself:
How big is your team? Under ten people? Don’t split.
Is your business stable? Still experimenting? Don’t split.
Do you need strong consistency? Yes? Don’t split.
Has anyone on the team done microservices before? No? Don’t split.
Microservices are not the goal. Solving business problems is. If your monolith is serving you well, don’t break it just because it’s trendy.
That company that spent two years splitting and then merged back? They’re doing fine. Their tech lead said something I haven’t forgotten:
“I used to think not splitting meant falling behind. Now I know—what fits is what’s advanced.”
What fits for you today?
