DynamoDB Hot-Key Simulator

DynamoDB distributes data across physical partitions and gives each one a baseline slice of the table's throughput. Adaptive capacity then reshapes that allocation, letting a busy partition borrow throughput other partitions are not using. Adaptive capacity reduces — but does not eliminate — the consequences of a pathological hot key: a single logical key still lives on exactly one physical partition, and that partition has a hard per-partition ceiling it cannot exceed no matter how much spare table capacity exists.

Toggle adaptive capacity below and push skew to the extreme to see all three regimes: throttling early without it, absorbed by spare capacity with it, and the partition ceiling that survives both.

Table configuration

Total table throughput (capacity units/s) 1,000/s

Number of physical partitions 10

Total traffic vs. table throughput (%) 40%

Traffic skew toward one key (0% = uniform, 100% = one hot key) 0%

Per-partition hard ceiling (capacity units/s) 3,000/s

Adaptive capacity ON — a hot partition may borrow throughput other partitions are not using (up to the ceiling)

Shard the hot key across 5 suffixes (e.g. HOTKEY#0 … HOTKEY#4)

Per-physical-partition traffic vs. budget

Each bar is one physical partition. The dashed line is that partition's effective budget: the baseline slice (total ÷ partitions), plus whatever adaptive capacity can lend it from idle partitions, capped at the per-partition ceiling. Red = incoming traffic exceeds the effective budget = throttled.

within effective budget above baseline, absorbed by adaptive capacity throttled (traffic > effective budget) idle / near-zero traffic

Why this matters

DynamoDB does not allocate throughput per logical item — it allocates it per physical partition. The mental model is a chain, not a single rule:

logical key
    ↓  (hash)
physical partition
    ↓
baseline capacity distribution  (table throughput ÷ partitions)
    ↓
adaptive capacity may rebalance available throughput toward hot partitions
    ↓
BUT
a single very hot item/key can still hit a per-partition ceiling

Adaptive capacity means an uneven access pattern is usually absorbed: a partition running hot borrows throughput that idle partitions are not using. It reduces, but does not eliminate, the consequences of a pathological hot key. Two limits survive it: the table's total capacity (you cannot lend what nobody has spare), and a per-partition/item ceiling that no amount of table capacity raises. That is why AWS still recommends designing partition keys that distribute I/O effectively.

When the ceiling is reached, throttling appears while the table-level consumed-capacity metric still looks healthy — see DynamoDB, "Hot keys" and "On-demand is not a hotspot cure."

Adaptive capacity OFF (the old static model, and still a useful worst case): the hot partition throttles as soon as it exceeds its baseline slice, however idle the rest of the table is.
Adaptive capacity ON: the hot partition absorbs spare table capacity and rides through moderate skew without throttling.
Extreme hot key: raise skew toward 100% and the hot partition hits the per-partition ceiling anyway — adaptive capacity has nothing left to lend, and the ceiling is not a budget you can buy your way past.
Adaptive capacity also does not react instantly; it rebalances over time, so a flash sale can throttle before it catches up.
Sharding the hot key (append a suffix 0..N-1, fan reads/writes across it) is the fix that changes the shape of the problem: the same logical entity's traffic now lands on N physical partitions, each with its own baseline and its own ceiling.
This is a simplified model — real partition counts, hashing, and splits depend on table size and throughput history.