What to ask your agency about monoliths and microservices

We end up explaining this on discovery calls often enough that it deserved writing down. If you are briefing an agency or a freelancer on monoliths and microservices, these questions are worth asking early.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Questions worth asking

• Who will actually do this work, and have they done it before?
• How will we know afterwards whether it worked?
• What happens if it needs changing in a year?
• What are you assuming that we have not confirmed?

What a good answer sounds like

A well-structured monolith beats a badly split set of services. The reasoning matters more than the rule, because the rule has exceptions. If it only works because one person remembers to do something, it does not work yet.

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.

In practice

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
• 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.