The Case Against Premature Microservices

Somewhere along the way, microservices stopped being an architectural decision made in response to a specific scaling problem, and became a default starting point. Teams of four engineers are shipping a dozen services before they have a single paying customer, because that is what the diagrams in the conference talks look like.

A monolith is not a mistake

A well structured monolith, with clear internal module boundaries, is not technical debt. It is the correct architecture for a team that is still discovering where its real boundaries are. Splitting a system into services encodes a set of assumptions about where the seams belong, permanently, in your network topology and your deployment pipeline. Getting those seams wrong inside a monolith costs you a refactor. Getting them wrong across services costs you a distributed rewrite, usually under production load.

We have watched early stage teams spend a third of their engineering time on service to service authentication, retry logic, and deployment orchestration, for a product that a single well organized codebase could have served with room to spare for another year of learning what the business actually needed.

The right trigger is a real constraint

We split services when there is a concrete reason: a team that needs to deploy independently because their release cadence has genuinely diverged, a workload with such different scaling characteristics that bundling it with the rest wastes real resources, or a security boundary that regulation actually requires. Those are constraints you can point to. Wanting to look like a serious engineering organization is not one of them.

Splitting a monolith is a one way door. Walk through it when you have to, not when it looks impressive.

The teams that scale smoothly are usually the ones who stayed boring the longest, and split only the piece that actually needed splitting, when the evidence for it was undeniable rather than aspirational.