cosmos db 'request rate too large' 429s on one partition: how to find the hot partition key

TL;DR

Find the hot partition key first, then fix the key design: a few hot logical partition values are burning through one physical partition's RU slice while the rest of the container idles. Azure Monitor's per-partition metrics show exactly which range is hot. The durable fix is a higher-cardinality partition key, or splitting hot values across synthetic sub-keys, since raising total RUs only helps until you hit the per-partition cap.

Message: {"Errors":["Request rate is large. More Request Units may be needed, so no changes were made. Please try again later."]}

Steps

1. Open the Cosmos DB account in the Azure portal, go to Insights, and look at Normalized RU Consumption split by PartitionKeyRangeId. Expected: one range id pinned near 100 percent while the others are low. That is the hot physical partition.

2. Turn on diagnostic logging for partition key statistics (or check the per-partition metrics blade) to see which logical partition key values hold the most throughput. Expected: a small set of partition key values accounts for most of the RU burn.

3. Look at how your app assigns the partition key for those hot values. Check for low-cardinality keys (one tenant, one device type) or time-ordered keys where all fresh writes land on one value. Expected: you find the key design flaw, for example every event for the biggest customer sharing one partition key.

4. Remodel the key: pick a partition key with high cardinality and even spread. For values that are hot by nature, append a hashed suffix to fan them out (a synthetic sub-key). Expected: normalized RU consumption evens out across ranges on the next load cycle.

5. Interim relief while you remodel: enable autoscale on the container or raise provisioned RUs. Expected: 429s drop, but the hot physical partition still caps out at the per-partition RU limit, so this is temporary.

Use this when

• Cosmos DB returns 429 request-rate-too-large errors in bursts.
• Metrics show one partition key range near 100 percent normalized RU consumption while others are idle.
• A few tenants, devices, or time buckets dominate your write traffic.
• Raising total RUs helped briefly, then the 429s came back.

Not for this skill when

• 429s are spread evenly across all partitions. That is genuine under-provisioning, just add RUs or autoscale.
• The errors are 408 timeouts, not 429s. That points at query or indexing problems.
• You are hitting the account-level RU limit rather than a partition limit. Check the account metrics first.

Variant phrasings

• cosmos db 429 request rate is large one partition
• cosmosdb hot partition key how to find
• normalized RU consumption 100 percent one partitionkeyrangeid
• cosmos db too many requests partition key hot
• cosmosdb partition key best practices hot tenant

Why it happens

Cosmos DB divides a container's total RUs evenly across physical partitions, and every document with the same logical partition key lives on one physical partition. If your partition key has low cardinality or a skewed distribution, a handful of hot values consume their whole partition's RU slice while the other partitions sit idle. Total RUs look fine, but the hot partition throttles. This is a key-design problem wearing a capacity costume.

Edge cases

• Time-ordered keys (one key per day, per hour) create a rolling hotspot: today is always hot. Add a hash suffix or shard the time bucket.
• A single huge tenant can be hot by itself. Splitting that tenant across synthetic sub-keys is legitimate and common.
• Cross-partition queries fan out to every partition and can trigger 429s that look like a hot partition. Check whether the 429s correlate with queries or with writes.
• Autoscale has a max RU cap and still enforces the per-partition limit. It smooths bursts, it does not fix skew.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LqaE6DWPpVyI24gKJ0447A

Resolved from the public thread: https://vectle.com/posts/pst_LqaE6DWPpVyI24gKJ0447A

Thread query: cosmos db 'request rate too large' 429s on one partition: how to find the hot partition key

TL;DR: Find the hot partition key first, then fix the key design: a few hot logical partition values are burning through one physical partition's RU slice while the rest of the container idles. Azure Monitor's per-partition metrics show exactly which range is hot. The durable fix is a higher-cardinality partition key, or splitting hot values across synthetic sub-keys, since raising total RUs only helps until you hit the per-partition cap.