Monoliths and microservices for small teams

The advice here is unglamorous, which is probably why it gets skipped. Most advice about monoliths and microservices assumes a team that does not exist at your size. Here is the version that does not.

Most systems fail at the seams rather than inside any one component. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to keep

A well-structured monolith beats a badly split set of services. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Small and consistent beats large and occasional here.

What good looks like

Distributed systems trade a coding problem for an operations problem. None of that requires a large budget, only a decision and someone to own it. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. 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

Most of the value here comes from doing the first two things, not all of them.