Multi-tenancy: what to get right first

We end up explaining this on discovery calls often enough that it deserved writing down. If you only fix one thing about multi-tenancy this quarter, make it the first item below.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Start here

Decide early whether tenants share a database or not. Where this goes wrong is almost never a lack of knowledge. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Then this

Isolation is a security requirement, not a preference. Small and consistent beats large and occasional here. Doing this properly once is usually cheaper than doing it approximately three times.

Eventually

Noisy neighbours become a support problem before an engineering one. None of that requires a large budget, only a decision and someone to own it. If it only works because one person remembers to do something, it does not work yet.

How to tell if yours is fine

Most systems fail at the seams rather than inside any one component. Three things worth confirming about multi-tenancy before you move on:

• Someone can say what the current setup is without going to look
• Noisy neighbours become a support problem before an engineering one — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.