Three myths about monoliths and microservices

There is no clever trick in this one, just a handful of decisions worth making deliberately. A few things about monoliths and microservices that get repeated more often than they get checked.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Budget a little time for it every quarter and it never becomes a project of its own.

“It only matters for big sites”

A well-structured monolith beats a badly split set of services. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

“We can deal with it after launch”

Sometimes true, usually expensive. Getting it slightly wrong is survivable. Ignoring it entirely is not.

“Our platform handles it”

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. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

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
• Distributed systems trade a coding problem for an operations problem — 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.