Why multi-tenancy matters more than it looks

This is one of those topics that looks small until it costs you something. Multi-tenancy is easy to treat as a detail, and that is exactly why it is worth a few minutes of attention.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If two people in the business would answer this differently, that gap is the actual problem.

Why this earns attention

Decide early whether tenants share a database or not. There is a version of this that is over-engineered, and it is worth avoiding. It rarely shows up as a line item, which is exactly why it slips.

Isolation is a security requirement, not a preference. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Common failure modes

Noisy neighbours become a support problem before an engineering one. The cost of getting this wrong is rarely visible on the day it happens. If two people in the business would answer this differently, that gap is the actual problem.

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

Most of the value here comes from doing the first two things, not all of them.