Design and build multi-tenant SaaS apps at scale with Azure Cosmos DB
summary
A Contoso-style payments app uses Cosmos DB and compares tenant isolation by partition key vs database account, showing trade-offs: shared containers (10,000 or 5,000 RUs examples) risk noisy neighbors while separate accounts give per-tenant settings. Partitioning details matter: physical partitions burst to 10,000 RUs, 50 GB physical / 20 GB logical limits, and hierarchical keys avoid hotspots. Kinectify runs a 200,000 RU transaction collection and a 50,000 RU player collection, measures 2.5 KB transactions at 13 RUs and achieves 15,380 transactions/sec ingest; final advice: pick a high‑cardinality surrogate key (they pick player/payer ID) and use dynamic autoscale to cut multi‑region cost.
AI-written summary · about
chapters (8)
- 0:00Session introduction
- 2:58Tenant isolation models
- 7:20Choosing the right strategy
- 9:37Partitioning principles
- 13:31Partitioning key experiment
- 20:32Connectify case study
- 35:54Production and security
- 39:14Scaling and final wrap-up
related talks
14mBest Practices for Building Multi-Tenant Applications on Azure Cosmos DB
01h 13mBuilding Planet Scale .NET Apps with Azure Cosmos DB
49mSQL Server vs Azure Cosmos DB
01h 00mCost cutting strategies for Azure Cosmos DB
52mPerformance tuning for Azure Cosmos DB
08mOptimize for the Best Cost and Performance for Azure Cosmos DB NoSQL API
01h 03mData Modeling and Partitioning in Azure Cosmos DB
48mPerformance tuning for Azure Cosmos DB