An ice-road convoy tracker starts receiving HTTP 429 responses from Cosmos DB after a teammate replaced point reads with broad SELECT * scans. What should the developer recognize as Cosmos throughput currency, and what should they prefer?
Select an answer to reveal the explanation.
Short Explanation
Cosmos charges in request units—think tokens at the arcade. Point reads are a cheap game; SELECT * scans burn the roll and earn you 429s when the key was already in your pocket.
Full Explanation
Cosmos DB measures operation cost in request units (RUs). Broad SELECT * scans consume far more RUs than point reads when the ice-road convoy tracker already knows keys, and exceeding provisioned throughput yields HTTP 429 throttling. Developers should treat RUs as the throughput currency and prefer cheaper point reads over unrestricted scans whenever id and partition key are available.
Virtual machine vCPU counts are not the Cosmos billing/throughput unit; adding App Service instances alone does not fix Cosmos RU exhaustion if each instance still issues expensive queries. Blob Storage ingress gigabytes throttling Cosmos and moving documents into Azure Files confuses unrelated services with Cosmos throughput. Azure Front Door cache hit ratio is not the Cosmos throughput limit; disabling CDN does not address RU consumption inside Cosmos.
Exam caveat: 429 responses should be handled with retry after the server-specified delay; simply raising RU/s without fixing query shape may mask wasteful access patterns and increase cost. Autoscale versus manual throughput changes how spikes are absorbed but RUs remain the meter. Operational check: capture diagnostics/RU charge on the SELECT * path versus a restored point-read path for the same convoy document, confirm 429s subside under the same provisioned RU/s, and keep point reads in the hot path.