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?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.