arthrop0d

Brief articles on varied topics.

DynamoDB Adaptive Capacity and Hot Partition Keys

amazon web servicesdatabasesperformance

DynamoDB adaptive capacity is an automatic mechanism that redistributes a table’s available read and write throughput when some partition keys receive much more traffic than others. It lets a hot key use more than its even share without increasing the table’s total provisioned capacity.

The problem: uneven traffic

A DynamoDB table is divided across physical partitions, which are internal storage and throughput units managed by the service. A partition key is the key attribute DynamoDB uses to distribute items. All items with the same partition-key value form a logical partition, sometimes called an item collection.

The terms sound similar, but they are different:

Suppose a table has 1,000 write capacity units (WCUs) provisioned and DynamoDB distributes that capacity across ten physical partitions. A WCU represents one write of up to 1 KB per second. An even allocation would give each physical partition roughly 100 WCUs.

Now imagine that one customer, device, or tenant becomes unusually active. Requests for that key may all reach one physical partition, while the other nine partitions are mostly idle. Without adaptive capacity, the busy partition could run out of its local allowance and throttle requests even though the table as a whole still has capacity available.

That is the hot partition problem: traffic is uneven, but the initial allocation is not.

Increasing the table from 1,000 to 2,000 WCUs might hide the problem, but it also increases the table’s total capacity and cost. Adaptive capacity tries to use capacity that is already available.

What capacity is being moved

DynamoDB measures read capacity units (RCUs) and WCUs. An RCU represents a read of up to 4 KB per second when strongly consistent; eventually consistent reads use half as much capacity. These units are the table’s throughput budget, not a fixed number of CPU threads or database connections.

Adaptive capacity changes how that budget is made available to different partitions. If one partition is busy and other partitions are not consuming their allocations, DynamoDB can allow the busy partition to consume more than its nominal share. The table’s provisioned total remains 1,000 WCUs in the example; capacity has been redistributed, not created.

The mechanism is automatic. There is no setting that names a hot key and no request to manually rebalance partitions. DynamoDB observes request traffic and adjusts its internal allocation as access patterns change.

How the adjustment works

The useful sequence is:

  1. Requests arrive for different partition-key values. DynamoDB hashes each value to distribute data across physical partitions.
  2. The service observes consumption. It can see that one partition is using its allowance heavily while other partitions have unused capacity.
  3. Adaptive capacity changes the effective allocation. The busy partition is permitted to consume more of the table’s available throughput, while idle partitions give up capacity they are not using.
  4. The allocation can change again. If the hot key cools down and another key becomes busy, the service can adapt to the new pattern.

The exact placement and rebalancing operations are internal implementation details. In some cases, DynamoDB can also isolate a hot logical partition or split storage for a hot item collection so that one key does not remain constrained by unrelated keys sharing the same physical partition. This is often described as splitting for heat. Applications should treat that as a service-managed optimization, not as a layout they can inspect or control.

Adaptive capacity is still bounded. A single physical partition has service limits, including maximum per-partition read and write throughput. A request pattern that concentrates more traffic than one partition can serve may still be throttled, even when the table has unused capacity elsewhere. The exact limits and behavior depend on the operation and current DynamoDB limits; they are not a substitute for a well-distributed key design.

What it does not fix

Adaptive capacity does not make a poor partition key uniformly good. If every request uses the same partition-key value, the workload is inherently concentrated. Adaptive capacity may help by giving that key more of the table’s available budget, but it cannot provide unlimited throughput to one key.

It also does not turn a burst into guaranteed success. A workload can be throttled while capacity is being adjusted, when the table has no unused capacity, or when a per-partition ceiling is reached. Application retries should use exponential backoff and jitter rather than immediately repeating a throttled request.

Indexes have their own capacity concerns. A global secondary index (GSI) has a separate key layout and, when provisioned, its own throughput settings. A key that is well distributed in the base table can still be hot in a GSI, and adaptive capacity must operate on the traffic pattern seen by that index.

Where you may see it

You usually do not call adaptive capacity directly. It is part of DynamoDB’s managed behavior, so it may first appear indirectly during an incident:

Those signals mean “this request could not be served within the relevant capacity limit,” not necessarily “the whole table is out of capacity.” Adaptive capacity reduces throttling caused by uneven use of otherwise available capacity, but it does not remove the need to inspect hot keys, indexes, request size, burst patterns, and table-level limits.

← All articles