Hot partitions and hot keys in DynamoDB, Cassandra and Kafka
Partitioned databases spread data across many partitions, each with its own throughput limit. If one key gets a large share of the traffic, its partition hits the limit even though the cluster as a whole is mostly idle.
What causes it
Capacity is per partition, not per table. A celebrity post, a global counter or a time-based key sends a big slice of requests to one partition. That partition throttles while the others have room to spare — adding nodes does not help, because the hot key still lives on one partition.
How to recognise it
- Throttling while total consumed capacity is well below provisioned
- Errors concentrated on a few keys
- DynamoDB “ProvisionedThroughputExceededException” on one partition key
The math
Hot partition load = λ × (hot key share + (1 − hot key share) ÷ partitions)
Error messages you will see
| Error | Seen in |
|---|---|
ProvisionedThroughputExceededException (hot partition) | Amazon DynamoDB |
How to fix it
- Spread the hot key (write sharding: key#1…key#N)
- Cache the hot item in front of the database
- Choose a partition key with more distinct values
Reproduce it in the simulator
These templates trigger this failure on purpose:
Learn more
Part of the guide Caching in system design.