A short guide to monoliths and microservices

Every audit we run turns up some version of this. Everything we would tell a client about monoliths and microservices in the time it takes to drink a coffee.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The reason this keeps coming up

A well-structured monolith beats a badly split set of services. Getting it slightly wrong is survivable. Ignoring it entirely is not. If it only works because one person remembers to do something, it does not work yet.

How to approach it

Split along boundaries the business already has, not along technical layers. Small and consistent beats large and occasional here. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What to watch for

Distributed systems trade a coding problem for an operations problem. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.

In practice

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

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.