DynamoDB Hot Partitions

A hot partition is a storage partition that receives far more traffic than its neighbors. One partition works at its limit while the others sit idle. Requests start failing even though the table as a whole has plenty of unused capacity.

The Checkout Lane Picture

A supermarket opens ten checkout lanes. Every customer joins lane one, and nine cashiers stand idle. Lane one grows a long queue, and shoppers get frustrated. A hot partition behaves like that single crowded lane. Good key design spreads customers across all ten lanes.

How DynamoDB Spreads Data

DynamoDB runs the partition key of each item through a hash function. The result decides which physical partition stores the item. Items with different keys land on different partitions, and items with the same key land together.

Every partition has fixed limits:

• Up to 3,000 read capacity units per second
• Up to 1,000 write capacity units per second
• Roughly 10 GB of stored data before DynamoDB splits it

What Makes a Partition Hot

Four patterns cause most hot partitions:

• A date as the partition key, because every write today targets today's value.
• A status value such as ACTIVE, because most items share the same few values.
• A very popular item, such as a trending product or a viral post.
• A sequence number that always increases, because new writes pile onto the newest key.

Signs of a Hot Partition

• Requests fail with ProvisionedThroughputExceededException while table-level usage looks low.
• CloudWatch shows rising throttle events for reads or writes.
• CloudWatch Contributor Insights reveals one key that dominates the traffic.

Adaptive Capacity

DynamoDB includes adaptive capacity, a feature that reacts to uneven traffic. The service shifts unused capacity toward busy partitions and can split a hot partition to separate frequently used items. Adaptive capacity softens many problems without any effort from you.

The feature has a hard ceiling. A single item lives on one partition, so one item cannot exceed the partition limits. A celebrity profile that receives 10,000 reads per second still needs a design fix or a cache.

Fix 1: Pick a High-Cardinality Key

Cardinality counts how many different values a key can take. A UserID with millions of values spreads traffic evenly. A Status key with three values concentrates traffic. Start every design by choosing a key with many distinct values.

Fix 2: Write Sharding

Write sharding adds a suffix to a popular key and spreads writes across several partitions. Consider a table that stores all events for one day.

BEFORE (hot)
PK = "2026-06-01"   → every write lands on one partition

AFTER (sharded with a random suffix 0-9)
PK = "2026-06-01#0"
PK = "2026-06-01#1"
PK = "2026-06-01#2"
...
PK = "2026-06-01#9"  → writes spread across ten partitions

Reading Sharded Data

A read must visit every shard and merge the results. Developers call this pattern scatter-gather.

Query PK = "2026-06-01#0"  ─┐
Query PK = "2026-06-01#1"   │
Query PK = "2026-06-01#2"   ├─→ Application merges all results
...                         │
Query PK = "2026-06-01#9"  ─┘

Fix 3: Calculated Suffix

A calculated suffix comes from the data itself instead of a random number. Your code computes a hash of an attribute, such as the OrderID, and uses the result as the suffix. Reads for a known order jump straight to the correct shard, so no scatter-gather is needed for that case.

OrderID  = "ORD-5521"
Suffix   = hash("ORD-5521") mod 10  = 4
PK       = "2026-06-01#4"

Fix 4: Cache Popular Reads

A cache absorbs repeated reads of the same item. DynamoDB Accelerator (DAX) or an application-level cache serves popular items from memory. The partition handles only cache misses.

Design Checklist

• List your most frequent access patterns before choosing keys.
• Estimate the busiest key in each pattern.
• Pick keys with many distinct values.
• Shard any key that may exceed 1,000 writes per second.
• Monitor throttle metrics after launch.

Summary

• A hot partition receives uneven traffic and throttles requests even when the table has spare capacity.
• Each partition supports 3,000 read units and 1,000 write units per second.
• Adaptive capacity helps, but one item can never exceed one partition's limit.
• High-cardinality keys, write sharding, calculated suffixes, and caching remove most hot spots.