A practical checklist for monoliths and microservices

Every audit we run turns up some version of this. Run through this the next time monoliths and microservices comes up.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If two people in the business would answer this differently, that gap is the actual problem.

The checklist

• A well-structured monolith beats a badly split set of services
• Split along boundaries the business already has, not along technical layers
• Distributed systems trade a coding problem for an operations problem
• Someone is named as the owner
• There is a date to review it again

Why it matters

A well-structured monolith beats a badly split set of services. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.

What this looks like day to day

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

Worth checking on your own setup before it becomes someone else's problem to fix.