Multi-Tenant Architecture: How deep down the rabbit hole should you go?

When it comes to Multi-Tenant Architecture (AKA “MTA”), there are many ways to design your system.

You can start by using the Tenant ID as part of your partition key. This could lead to oddly distributed partition sizes, but it’s a start.

You can give each tenant their own dedicated DB cluster while using the same application layer for all the tenants. You would have to write code in the application layer so it knows which DB cluster to use for each client.

If your workload is computationally intensive in the background and you have a lot of event-driven queues and workers that get backed up if a tenant queues up too many big reports at once, you will definitely want to give each tenant their own infrastructure.

You could give each tenant their own bucket and dedicated KMS keys to encrypt what is in those buckets.

Finally, if you really wanted to, you could give each client their own application layer. This is kind of a pain because every time you deploy new code, you will need to deploy it once for each customer you have. A similar argument could be made for DB migrations as well, I suppose.

What solution is right for you? First, we have to answer a few questions.

Do you have a few really big customers or many small ones?

The more customers you have, the bigger the maintenance costs of all the parallel services get.

How important is security to the customer?

If they really want their data isolated, then I would lean towards the higher levels of MTA.

How computationally performant do they need to be?

If they really want to be sure another customer’s workload cannot affect the performance of the application for them, then the higher levels of MTA might be for them.

If you need help calculating the ROI on your investment into MTA or any other cloud tech, I have a workshop for this that can help you get the best bang for your buck.

Shoot me a message if you want to learn more.