How DynamoDB Adaptive Capacity Handles Hot Partitions Without Schema Changes

The problem: throttling despite unused capacity

When a DynamoDB table is provisioned with a fixed number of read or write capacity units (RCUs/WCUs), each partition gets an equal share of that throughput. If a single partition key—say a popular user ID, a top‑scoring game player, or a frequently reporting IoT device—receives far more requests than its share, the table throttles those requests even though other partitions sit idle. Overall utilization can look low, but the hot partition experiences 429 errors and increased latency.

Thesis: Adaptive Capacity automatically borrows from cooler partitions

DynamoDB Adaptive Capacity monitors the request rate per partition. When a partition exceeds its allocated throughput, the service draws unused capacity from other partitions and temporarily assigns it to the hot key. This happens transparently: no schema changes, no manual re‑tuning, and no need to switch to on‑demand mode. The borrowed capacity is returned to the pool as soon as the hot traffic subsides.

How it works – behind the scenes

1. The service continuously measures consumed RCUs/WCUs per partition.
2. If a partition’s consumption > its provisioned share, Adaptive Capacity checks the aggregate unused capacity across all partitions.
3. It reallocates a portion of that unused capacity to the hot partition, allowing the excess traffic to be served.
4. The reallocation is invisible to the client; the API still sees the original provisioned throughput as the limit, but latency stays low because the extra capacity is physically available.

This mechanism only works for tables provisioned with RCUs/WCUs. On‑demand tables already scale per request and do not use Adaptive Capacity.

Worked example: leaderboard burst

Imagine a multiplayer game that writes a score update for the current top player 500 times per second. The table is provisioned with 10 WCUs, which translates to roughly 10 writes per second per partition (assuming uniform distribution). Without Adaptive Capacity, the hot partition would throttle after about 10 writes/sec.

With Adaptive Capacity enabled (the default for provisioned tables):

• The leaderboard partition consumes far more than its 10 WCU share.
• Other partitions, perhaps storing inactive player profiles, are idle and have unused WCUs.
• Adaptive Capacity borrows from those idle partitions, effectively giving the leaderboard partition access to, say, an additional 40 WCUs for the duration of the burst.
• The 500 writes/sec succeed, latency remains low, and the idle partitions experience no impact because they were not using their capacity.

To try this yourself, you can run the following commands in a terminal with AWS CLI v2. Ensure you have dynamodb:CreateTable, dynamodb:PutItem, and cloudwatch:PutMetricData permissions (the latter only if you push custom metrics; otherwise just rely on CloudWatch defaults).

# 1. Create a provisioned table with modest WCUs
 aws dynamodb create-table \
     --table-name GameScores \
     --attribute-definitions AttributeName=PlayerId,AttributeType=S \
     --key-schema AttributeName=PlayerId,KeyType=HASH \
     --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=10 \
     --table-class STANDARD

# 2. Simulate a hot key (replace <HOT_PLAYER_ID> with a fixed string)
 aws dynamodb put-item \
     --table-name GameScores \
     --item '{"PlayerId":{"S":"<HOT_PLAYER_ID>"},"Score":{"N":"0"},"Timestamp":{"N":"'$(date +%s)'"}}' \
     --return-consumed-capacity TOTAL

# Repeat the put-item in a tight loop (e.g., using a small script) to exceed 10 WCUs.
# 3. Monitor CloudWatch: look for ConsumedWriteCapacityUnits staying near 10 while SuccessfulRequestLatency remains low.

Note: Running a tight loop will increase your AWS charges for write requests and may generate throttling if the borrowed capacity is exhausted. Stop the loop after you observe the behavior to avoid unnecessary cost.

Trade‑off and limitation

Adaptive Capacity excels when traffic is uneven but not permanently skewed. If a single partition consumes >90% of the provisioned throughput for an extended period, the pool of unused capacity can become depleted, and throttling returns. In that scenario you must reconsider the data model:

• Add a random suffix or numeric shard to the partition key to spread the load.
• Use a composite key that incorporates a time‑based element.
• Switch to on‑demand mode if the workload is unpredictable.

The feature does not replace a well‑chosen partition key; it merely buys you time to redesign the key when hot spots emerge.

Actionable closing

Adaptive Capacity is enabled by default on all provisioned DynamoDB tables, so you likely already benefit from it. To verify it is working for your table:

1. In the AWS Console, open the table, choose the “Capacity” tab, and confirm that “Adaptive capacity” appears as enabled.
2. Set up a CloudWatch alarm on SuccessfulRequestLatency or ThrottledRequests for your table.
3. If you see persistent throttling despite low overall utilization, examine the partition key distribution (e.g., via describe-table and scan on a sample) and consider a sharding strategy.

By monitoring these metrics and acting when the borrowed capacity is exhausted, you can keep your application responsive without over‑provisioning or migrating to on‑demand prematurely.