When monoliths and microservices is worth the effort

Teams tend to reach for this after something has already gone wrong. Monoliths and microservices is not free, and pretending otherwise leads to bad decisions.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

When it is worth it

A well-structured monolith beats a badly split set of services. The teams that handle this well are rarely the ones with the biggest budgets. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. The reasoning matters more than the rule, because the rule has exceptions.

How to decide

Distributed systems trade a coding problem for an operations problem. In practice this is a scheduling problem more than a technical one. Assume whoever inherits this will have half your context and none of your patience.

The short version

Most systems fail at the seams rather than inside any one component. Three things worth confirming about monoliths and microservices before you move on:

• Someone can say what the current setup is without going to look
• Split along boundaries the business already has, not along technical layers — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.