Hot Partitions
Detect and relieve keys or shards that receive disproportionate traffic.
2–5 minute refresher
Timeout→Backoff→Jitter→Retry budget→Circuit breaker→Load shedding
Average capacity hides the hottest ownership unit
30second
refresher
refresher
A hot partition receives enough concentrated traffic to saturate its owner even when the cluster has spare aggregate capacity. The cause may be one key, one tenant, a time-leading range, or skewed routing.
What problem does it solve?
Capacity planning based on averages misses concentrated demand. One saturated shard raises tail latency, queues requests, and can trigger retries that spread failure outward.
How it works
- Rank partitions and keys by requests, bytes, CPU, and latency.
- Classify the hotspot as read-heavy, write-heavy, or mixed.
- Cache or replicate read-heavy keys.
- Split, salt, or aggregate write-heavy keys while preserving required ordering.
- Apply tenant isolation, admission control, and load shedding when demand exceeds safe capacity.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Key salting | Parallel write capacity | Fanout reads and lost per-key order |
| Hot-key cache | Absorb repeated reads | Invalidation and staleness |
| Dedicated shard | Fault and capacity isolation | Poor utilization outside peaks |
What happens if?
A celebrity event creates one viral key
Automatic shard movement moves the problem rather than divides it. Replicate or cache the read path, coalesce requests, protect the backing store, and degrade optional detail before queues saturate.
Where it appears
- DynamoDB adaptive capacity
- Redis hot-key controls
- CDN request coalescing
- Kafka key salting
Senior interview modeWhy might adding ten nodes not improve a hot partition?Show answer
If one key or unsplittable range owns the bottleneck, normal routing still sends all of its work to one ownership unit. The access pattern or key representation must change.