From Monolith to Microservices (and Sometimes Back Again)
Microservices aren’t always the answer. Here’s a practical way to think about when to split systems, when to stay monolithic, and when to do nothing.
Who this is for
This post is for founders and engineers building early-stage products who are trying to decide whether they should stay with a monolith, move to microservices, or refactor what they already have.
Microservices are tempting.
They promise clean boundaries, independent deployments, and better scaling. Blog posts and conference talks make it sound like the “correct” architecture once things get serious.
But in practice, I’ve worked on systems that tried all three approaches:
- a single large monolith
- multiple microservices
- and awkward hybrids in between
Here’s what actually matters.
Why Microservices Sound So Good
On paper, microservices give you:
- independent deployments
- team autonomy
- freedom to scale parts of the system separately
And these benefits are real — at the right time.
The problem is that many teams reach for microservices before they’ve earned them.
The Hidden Cost of Microservices
Splitting a system doesn’t remove complexity.
It moves it.
Operational Overhead
With microservices, you now need:
- service discovery
- centralized logging
- distributed tracing
- health checks across services
- deployment orchestration
That’s a lot of infrastructure before you’ve even shipped real features.
Debugging Becomes Harder
In a monolith, a stack trace often tells you exactly what went wrong.
In microservices, you’re tracing a request across:
- multiple services
- network boundaries
- message queues
When something breaks, finding the root cause takes longer.
Data Consistency Is Now Your Problem
In a monolith, you usually have transactions.
In microservices, you have:
- eventual consistency
- retries
- partial failures
- compensation logic
All of this needs to be designed carefully — or you end up with subtle bugs that are hard to reproduce.
When a Monolith Is the Better Choice
Small Teams
If a small team can understand most of the codebase, a monolith is often simpler and faster.
You spend less time coordinating and more time shipping.
Early-Stage Products
Early on, you don’t yet know:
- what features will survive
- where the real complexity lies
- which parts need to scale
A monolith lets you change direction without fighting your architecture.
Tightly Coupled Domains
If features constantly touch each other, splitting them just adds network calls where function calls used to be.
That’s rarely a win.
When Microservices Start to Make Sense
Multiple Teams
When different teams own clearly separate parts of the product, service boundaries can reduce coordination overhead.
Truly Independent Domains
Things like payments, notifications, or analytics often evolve independently and can be good candidates for extraction.
Different Scaling Needs
If one part of your system needs far more resources than the rest, separating it can make scaling more efficient.
The Middle Ground: A Modular Monolith
Before jumping to microservices, consider a modular monolith:
- one codebase
- clear module boundaries
- communication through defined interfaces
- shared database with discipline
This gives you many of the organizational benefits without the operational burden.
If a module outgrows the monolith later, you can extract it with less pain.
A Simple Decision Framework
- Start with a monolith
- Pay attention to real pain, not future hypotheticals
- Split only when boundaries become obvious
- Optimize for team clarity, not architectural purity
Related Reading
If you're thinking about architecture decisions for your startup:
- How I Build MVPs That Don't Need a Rewrite — optimize for change, not scale
- Why I Choose Boring Technology — predictable tools over shiny frameworks
- My Services — if you need help with system architecture
Final Thought
Architecture isn’t about trends or ideology.
It’s about choosing the simplest system your team can understand, ship, and maintain reliably.
Most of the time, that system is simpler than you think.