Azure DocumentDB Multi-Tenant Architecture

Question

I've been implementing DocumentDB during preview into a multi-tenent system. My plan has been to generate a new database under the DocumentDB account for each tenant that signs up. Most of this code is already in place and the testing is going extremely well.

Since DocumentDB has been officially released and the documentation is finalized I read about the 100 database limit per DocumentDB account and it made me stop to rethink my architecture.

I wanted to keep my tenants isolated so that deleting accounts would be easy, and the organization of it would be very clean. Data between tenants do not need to interact so keeping it separated would not be an issue.

My questions:

Since my goal is to make this scale up to tens or even hundreds of thousands of tenants, do I need to consider a different architecture due to DocumentDB limitations and/or cost?

Does this mean I need to shard every 100 accounts across multiple DocumentDB accounts?

According to Microsoft the limit of 100 databases is just a soft limit that can be scaled up upon request, but can it go up to 100,000+ if needed? What if I get more account sign-ups that expected and I hit my limits in production potentially losing clients?

Does this limitation exist as a way to deter developers from partitioning tenants in this fashion for good reason that I should be considering?

Answer 1

There's no such thing as a one-size-fits-all answer when it comes to partitioning / sharding tenant data. Generally, how you partition data depends on your application's query patterns as well as the resource requirements per tenant (in terms of both storage and throughput). Just keep in mind that collections are DocumentDB's unit of boundary for transactions and queries.

Check out the blog post as user272735 mentioned in the comment above: Scaling a Multi-Tenant Application with Azure DocumentDB. It's a great read.

If you need to some more 1:1 guidance for your particular scenario or database/collection limits relaxed, feel free to ping me at andrl {at} microsoft.com.