Five mistakes teams make with multi-tenancy

The version of this that works is simpler than the version most people imagine. These are the ones we run into repeatedly when we audit multi-tenancy.

Most systems fail at the seams rather than inside any one component. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The mistakes we see most

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Decide early whether tenants share a database or not
• Isolation is a security requirement, not a preference
• Never checking whether the fix actually worked

Noisy neighbours become a support problem before an engineering one. Where this goes wrong is almost never a lack of knowledge. Doing this properly once is usually cheaper than doing it approximately three times.

A reasonable first step

The short version

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
• 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.