A practical checklist for multi-tenancy

Most teams know this matters. Fewer have decided who owns it. Run through this the next time multi-tenancy comes up.

Most systems fail at the seams rather than inside any one component. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The checklist

• Decide early whether tenants share a database or not
• Isolation is a security requirement, not a preference
• Noisy neighbours become a support problem before an engineering one
• Someone is named as the owner
• There is a date to review it again

The reason this keeps coming up

Decide early whether tenants share a database or not. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

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

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