maarkn.dev
Back to all posts
·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.