Planet scale or planet fail?
summary
Cosmos DB delivers global replication and guaranteed low-latency only if partitioning and client behavior are correct: partition key design controls throughput per partition (example: a 10,000 RU/s collection split into five partitions yields ~2,000 RU/s per partition), provisioning starts at 400 RU/s minimum, misusing the id field causes massive cost (a sample query costs ~3 RUs vs 177 RUs when querying id), clients must reuse a singleton DocumentClient, call OpenAsync, prefer direct TCP and set max degree of parallelism = -1 to avoid 429 throttles and wasted spend.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:52Cloud data evolution
- 3:20Cosmos DB overview
- 6:05Partitioning and throughput
- 9:43Replication and consistency
- 12:37API support and architecture
- 14:38Practical demo and metrics
- 26:19Local development experience
- 28:33Design pitfalls
- 35:18Client-side considerations
- 45:00Summary and resources
- 52:54Q&A session
related talks
52mPerformance tuning for Azure Cosmos DB
01h 13mBuilding Planet Scale .NET Apps with Azure Cosmos DB
46mDesign and build multi-tenant SaaS apps at scale with Azure Cosmos DB
01h 00mCost cutting strategies for Azure Cosmos DB
48mPerformance tuning for Azure Cosmos DB
49mSQL Server vs Azure Cosmos DB
01h 02mAzure Cosmos DB - Low Latency and High Availability at Planet Scale
08mOptimize for the Best Cost and Performance for Azure Cosmos DB NoSQL API