Using DynamoDB Adaptive Capacity to Absorb Hot‑Key Writes Without Manual Scaling

The hot‑key problem in DynamoDB

When a single partition key receives a burst of write traffic, DynamoDB can throttle requests even if the table’s overall provisioned capacity is under‑utilized. This happens because provisioned throughput is split evenly across partitions, and a “hot” key can exceed the per‑partition limit while other partitions sit idle.

How Adaptive Capacity works

Adaptive Capacity automatically redirects unused provisioned throughput from cooler partitions to the hot partition, up to four times the average partition size. The feature is available for both provisioned and on‑demand tables and requires a partition key with sufficient cardinality so that most partitions remain cool enough to donate capacity.

Enabling and verifying Adaptive Capacity

1. Enable the feature (requires dynamodb:UpdateTable permission):

   aws dynamodb update-table \
       --table-name Leaderboard \
       --adaptive-capacity-enabled true \
       --region us-east-1
   

2. Check the setting (read‑only, dynamodb:DescribeTable):

   aws dynamodb describe-table \
       --table-name Leaderboard \
       --query 'Table.AdaptiveCapacityEnabled' \
       --region us-east-1
   

3. Monitor effectiveness using CloudWatch:
   • AdaptiveCapacityThrottleEvents – should drop toward zero when the feature absorbs hot‑key traffic.
   • ConsumedWriteCapacityUnits and ThrottledRequests – compare before/after enabling.

Risk note: Enabling Adaptive Capacity does not change the table’s provisioned capacity; you still pay for the provisioned throughput you configured. If you over‑provision, cost rises without performance gain.

Worked example: gaming leaderboard burst

Suppose a leaderboard table is provisioned with 2000 WCUs, evenly spread across 20 partitions (100 WCUs per partition). During a peak event, a single player ID receives 150 k writes per second, which translates to roughly 1500 WCUs needed for that key alone.

• Without Adaptive Capacity: the hot partition exceeds its 100 WCU limit, causing throttling. CloudWatch shows a spike in ThrottledRequests and AdaptiveCapacityThrottleEvents remains high.
• With Adaptive Capacity enabled: the idle partitions (each with ~100 WCU unused) donate capacity. The hot partition can draw up to 4× its average (400 WCU) from the pool, reducing throttling. In the brief’s gaming example, 5xx errors fell from 12% to under 1% during a 150k writes/second burst.

To reproduce the verification steps:

1. Create a table with provisioned capacity: aws dynamodb create-table ... --billing-mode PROVISIONED --read-capacity 500 --write-capacity 2000.
2. Enable Adaptive Capacity as shown above.
3. Run a load‑generator that targets a single partition key (e.g., a loop writing to playerId=hotUser).
4. Observe CloudWatch metrics: AdaptiveCapacityThrottleEvents should trend down while ConsumedWriteCapacityUnits approaches the provisioned limit.

Trade‑offs and monitoring

• Limitation: Adaptive Capacity cannot help if a single partition key exceeds the table’s maximum per‑partition throughput (≈ 4000 WCUs for provisioned mode or the on‑demand per‑partition limit). In that case, you must redesign the key or use on‑demand mode.
• Cost consideration: Unused capacity is still paid for in provisioned mode. Monitor Utilization (Consumed/Provisioned) to avoid paying for idle capacity that never gets redistributed.
• Latency overhead: The redistribution adds a small, typically sub‑millisecond delay; most workloads see negligible impact.

Actionable closing

If you see throttling spikes correlated with a hot partition key, enable Adaptive Capacity as a low‑effort first step. Verify with the AdaptiveCapacityThrottleEvents metric and check that your partition key has enough cardinality to keep most partitions cool. If throttling persists despite the feature, consider redesigning the access pattern or switching to on‑demand capacity.