This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
Designing a multitenant system puts a hard requirement on a designer to do not leak data between tenants. Is there anyone who would like to show a list of employees’ emails from one company to another?
Azure Table Storage is a part of Azure Storage Services. It’s mentioned in the original Windows Azure Storage whitepaper and provides a stable foundation with known limitations, quotas and API that hasn’t changes for ages (ok, years). The most important aspect of it is the throughput which limited in two dimensions:
These two numbers can impact the performance of an app and should be taken into consideration when designing storage.
There’s a library which provides an event sourcing store on top of the Azure Table Storage. It’s called StreamStone. It provides a lot of capabilities but not a from-all projection (see this PR for more info, including my notes). This can be added (not easily), which I’ve done introducing some overhead on the write side.
Having a storage problem solved, how would you define and design a multitenant system?
The initial attempt could be to add the company identifie r to the partition key. Just use it as a prefix. That could work. Until one of the following happens:
It looks that this could work, but it could fail as well. So it’s not an option.
Fortunately, Azure provides management API for storage accounts. This means that from an application, one can instantiate storage accounts under the same subscription but totally separated from each other. Like in a container or something. This boxes performance limitations for a company into its own account. The problem of a potential leakage is also addressed by storing data of a company in a totally separated account.
As mentioned by Adrian in the comments, there’s a limit of 200 storage accounts per single subscription which is a high number to reach. Once you do it, additional layer of subscription management should be applied.
Of course there’s a need of a governor. A module that will know all the accounts and that will manage them. This, is a limited surface of possible leakage, leaving a good separation for the rest of the application/system.
Azure does have a limit for storage account per subscription, so you have to spread across subscriptions.by Adrian at 2016-11-29 11:11:56 +0000
that's correct there's a limit of 200 accounts per subscription. I'll amend the content. On the other hand, I'd like my startup to hit this limit with 200 separate enterprise licenses. It'd be a nice problem to solve, wouldn't it? ;-)by Szymon Kulec 'Scooletz' at 2016-11-29 20:47:00 +0000