·6 min read·
- Architecture
- Scaling
When to actually leave the monolith
I've migrated a few services to microservices. Most of those migrations didn't have to happen. Here's the litmus test I now use before recommending the split.
when-to-leave-the-monolith
Microservices are the spinach of our industry. Everyone says they're good for you, nobody asks if you'd rather have a salad.
I've worked on three migrations from monolith to microservices. Two of them were premature. The teams were small, the deploys were fine, the bottleneck wasn't architectural. We split anyway, and inherited a network where there used to be a function call.
The litmus test
I now ask three questions before recommending a split:
- Are different parts of the system on different release cadences? Not "could be" — actually are.
- Do different teams own different domains, and are they blocking each other?
- Is there a part of the system whose scaling shape is genuinely different from the rest?
If two of three answers are yes, split. Otherwise: the monolith you have is the easier one to evolve. A clean module is worth more than a clever service mesh.