Introduction

DynamoDB throttling is not always a simple table-wide capacity problem. A table can have spare total capacity and still throttle because one hot partition key is consuming an uneven share of reads or writes. The best fix depends on whether the problem is bursty traffic, a bad key design, or an application that retries too aggressively.

Symptoms

  • Requests fail with ProvisionedThroughputExceededException or ThrottlingException
  • CloudWatch shows rising ThrottledRequests
  • The issue appears during specific workloads, tenants, or partition key values
  • Client retries amplify the traffic spike instead of smoothing it out

Common Causes

  • Provisioned capacity is too low for the current request rate
  • One or a few partition keys are hot and absorb most of the traffic
  • The client retries immediately without exponential backoff
  • A bursty workload would fit better on on-demand capacity than on static provisioning

Step-by-Step Fix

  1. 1.Inspect throttling metrics and workload shape
  2. 2.Confirm whether the problem is sustained throughput pressure or a hotspot that only appears during certain keys or traffic spikes.
bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ThrottledRequests \
  --dimensions Name=TableName,Value=my-table \
  --start-time 2026-04-10T05:30:00Z \
  --end-time 2026-04-10T06:30:00Z \
  --period 300 \
  --statistics Sum
  1. 1.Add proper client retry backoff
  2. 2.Standard AWS SDK retries help, but applications that retry too fast can turn a short throttle event into a prolonged outage.

```python from botocore.config import Config

config = Config(retries={"max_attempts": 5, "mode": "standard"}) ```

  1. 1.Decide whether the key design is creating a hot partition
  2. 2.If the workload repeatedly hammers one partition key, raising table-wide capacity may only delay the next throttle event.
  3. 3.Adjust capacity mode to match the workload
  4. 4.Bursty or unpredictable workloads often recover fastest by moving to on-demand, while stable high-throughput systems may be better served by explicit provisioned tuning.
bash
aws dynamodb update-table \
  --table-name my-table \
  --billing-mode PAY_PER_REQUEST

Prevention

  • Design partition keys for even traffic distribution
  • Use exponential backoff and jitter in every client path
  • Monitor throttling alongside the specific operations and keys involved
  • Re-evaluate capacity mode when traffic becomes burstier or less predictable