Monolith to microservices: the split is usually an org problem

Thinking about breaking your monolith into microservices? The teams that have already done it mostly did it for org reasons, not technical ones. If what you actually have is a deploy coordination problem, more services will not solve it.

The argument is worth two minutes of your time, because it can save you a Kubernetes bill and a year of plumbing. A single Postgres box and a boring monolith will outrun that cluster until you are genuinely big.

What Happened

The claim is blunt: almost every monolith-to-microservices split was driven by team structure, not by scale. What feels like a scaling problem is usually a deploy coordination problem, where too many people are shipping through one pipeline at once. A single Postgres instance and a plain monolith keep up with a Kubernetes cluster until the company is actually large. And tech debt is not the enemy; pretending it is not there is.

Why It Matters

Before you add a service, ask what breaks if that code stays in the same repo. Most of the time, the answer is nothing. Start with one database, one deploy, and clear module boundaries inside the monolith, and let those boundaries do the work a network call would have done. Split later, when a real team boundary forces it, like a separate group that needs to ship on its own schedule. That keeps your operational cost low and defers the microservice tax until you have a reason to pay it.