What Happens When a DynamoDB Partition Key Receives Excess Traffic?

When a single partition key in Amazon DynamoDB receives a disproportionately high volume of read or write requests, it creates a scenario known as a "hot partition" or "hot key." DynamoDB distributes database workload and storage across multiple physical partitions based on the hash value of the partition key. Because the throughput provisioned for a table (or allocated automatically via auto-scaling) is distributed across all physical partitions, concentrated traffic on a single key can overwhelm the specific partition hosting that key, leading to performance bottlenecks and application-level errors.

The Dynamics of Partition Allocation

DynamoDB manages capacity by splitting data into separate storage partitions. Each partition has strict physical limits, supporting a maximum of 1,000 write capacity units (WCUs), 3,000 read capacity units (RCUs), or a combination thereof, up to a total storage cap of 10 GB.

When you allocate throughput to a table, DynamoDB divides that capacity across the underlying partitions. If your workload generates traffic evenly across millions of distinct partition keys, performance remains steady. However, if traffic concentrates on one partition key, that single key cannot exceed the single partition's maximum capacity limits, regardless of how much total capacity is provisioned for the entire table.

Primary Consequences of Excess Traffic

When requests to a single partition key exceed allowed limits, several distinct issues occur:

  • Throughput Exceeded Exceptions: DynamoDB rejects excess requests and returns a ProvisionedThroughputExceededException to the client application.
  • Request Throttling: Reads and writes directed at the hot partition are throttled, introducing retry latency or outright transaction failures for application users.
  • Unbalanced Partition Splitting: As storage or throughput demand grows, DynamoDB may split the partition into smaller chunks. If the heavy traffic is driven by a single key, splitting the partition does not solve the issue, as all traffic for that key still routes to one physical partition.
  • Impact on Global Secondary Indexes (GSIs): If the hot item is replicated to a Global Secondary Index with a similar key structure, throttling on the GSI will backpressure and throttle writes on the base table as well.

Mitigation Strategies for Hot Partition Keys

Resolving hot key issues requires altering how data is distributed or changing how frequent access patterns interact with the database.

1. Partition Key Write Sharding

Add a random or calculated suffix to the partition key value (for example, appending a random number between 1 and 10, such as USER_1234_1). This spreads the writes across multiple distinct physical partitions. When reading the data, the application queries all sharded keys and aggregates the results.

2. Caching Layer Integration

For read-heavy workloads, implement Amazon DynamoDB Accelerator (DAX) or an in-memory caching system like Redis/Memcached. Caching offloads repetitive read requests for popular keys away from DynamoDB entirely.

3. Combining Attributes

Create composite partition keys by combining multiple values (such as Date#TenantID#UserID). This increases key cardinality and ensures traffic splits evenly across the database infrastructure.