A short guide to multi-tenancy

It comes up on almost every project, usually later than it should. Everything we would tell a client about multi-tenancy in the time it takes to drink a coffee.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The reason this keeps coming up

Decide early whether tenants share a database or not. Where this goes wrong is almost never a lack of knowledge. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

How we handle it

Isolation is a security requirement, not a preference. It is worth being explicit about, because assumptions differ quietly. Doing this properly once is usually cheaper than doing it approximately three times.

Warning signs

Noisy neighbours become a support problem before an engineering one. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What this looks like day to day

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about multi-tenancy before you move on:

• Someone can say what the current setup is without going to look
• Decide early whether tenants share a database or not — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.