What's changed: Created DP-420 Chapter 1 (Domain 1 first-half: non-relational modeling (embed vs reference/denormalize/id-partition key-unique keys/default TTL/versioning); partition design (key choice/hot partition-429/cross-partition cost/data-throughput distribution/synthetic key/hierarchical key/single-logical-partition transactions); sizing and scaling (RU/s/serverless vs provisioned vs free/autoscale/database-level throughput/global-distribution cost)).
1.3Sizing and scaling
Understand evaluating throughput/storage requirements, request units (RU/s), serverless vs provisioned vs free tier, autoscale, database-level throughput, and global distribution cost.
Cosmos DB cost and performance are measured in request units (RU). Reads/writes/queries each consume RU, the unit of both billing and throughput. Choosing the throughput model that fits requirements is a key design point.
1.3.1Serverless, provisioned, and free tier
Serverless bills only the RU consumed—good for intermittent/unpredictable/low-traffic dev and small scale. Provisioned throughput reserves RU/s—good for steady/high-traffic production. Provisioned comes as manual (fixed RU/s) and autoscale (auto-varies 10%–100% within a max); highly variable workloads use autoscale to follow peaks while cutting idle cost. The free tier grants a fixed amount of RU/s and storage per account at no charge.
1.3.2Throughput granularity and global-distribution cost
Throughput is configured at the container level (dedicated to that container) or database level (shared by multiple containers in the DB). To run many small containers cost-effectively, database-level provisioning helps. In global distribution, each added region adds that region’s provisioned RU/s to the cost (multi-region writes add more), so weigh availability/latency requirements against cost.
Cues: "intermittent/unpredictable/low traffic" = serverless. "steady/high-traffic prod" = provisioned (manual). "highly variable" = autoscale. "many small containers shared" = database-level throughput. "adding a region adds its RU/s cost." RU is the billing/throughput unit for reads/writes/queries.
Watch the mix-ups: (1) Serverless (consumption billing, mostly single-region) vs provisioned (reserved RU/s). (2) Autoscale varies 10%–100% of the max—not always at max. (3) Database-level sharing tends to distribute evenly; a hot container may need dedicated throughput. (4) Insufficient RU yields 429 (rate limiting)—handle with SDK retries.
1.3.3Section summary
- RU/s is the billing/throughput unit—choose serverless (consumption), provisioned (reserved), or autoscale (variable) by requirement
- Throughput is configured at container level or database level (shared by multiple containers)
- Each added region adds RU/s cost—balance availability/latency against cost
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want a small dev Cosmos DB with intermittent, unpredictable traffic billed only for what you use. Best?
Q2. For a variable production workload, you want to follow peaks while cutting idle cost. Best?
Q3. You want many small containers to share throughput cost-effectively. Best?
Q4. What is the correct cost impact of adding a region for global distribution in Cosmos DB?
Q5. What does Cosmos DB return when provisioned RU/s is insufficient?