Getting started with multi-tenancy
Teams tend to reach for this after something has already gone wrong. A short on-ramp to multi-tenancy for teams who have not touched it before.
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What it costs to ignore
Decide early whether tenants share a database or not. That sounds obvious written down. It is still the thing most often skipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Your first week
- Find out what is already in place
- Isolation is a security requirement, not a preference
- Change one thing and measure it
Noisy neighbours become a support problem before an engineering one. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
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 multi-tenancy before you move on:
- Someone can say what the current setup is without going to look
- Isolation is a security requirement, not a preference — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If any of that sounds like a description of your current setup, it is fixable.