Multi-tenancy: the questions we get asked most

It comes up on almost every project, usually later than it should. The questions about multi-tenancy that come up most often on our calls.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Do we need to care about this?

Decide early whether tenants share a database or not. There is a version of this that is over-engineered, and it is worth avoiding. If two people in the business would answer this differently, that gap is the actual problem.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. Small and consistent beats large and occasional here.

How do we know it is working?

Noisy neighbours become a support problem before an engineering one. Getting it slightly wrong is survivable. Ignoring it entirely is not. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

Most systems fail at the seams rather than inside any one component. Three things worth confirming about multi-tenancy before you move on:

• Someone can say what the current setup is without going to look
• Noisy neighbours become a support problem before an engineering one — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.