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?
