When multi-tenancy is worth the effort

This is one of those topics that looks small until it costs you something. Multi-tenancy is not free, and pretending otherwise leads to bad decisions.

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.

When it is worth it

Decide early whether tenants share a database or not. This is the sort of thing that compounds, quietly, in both directions. If two people in the business would answer this differently, that gap is the actual problem.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. Small and consistent beats large and occasional here.

How to decide

Noisy neighbours become a support problem before an engineering one. There is a version of this that is over-engineered, and it is worth avoiding. Doing this properly once is usually cheaper than doing it approximately three times.

How to tell if yours is fine

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