DynamoDB Rate Limiting: Strategies for Single Table Design at Scale
Practical strategies to prevent and handle DynamoDB throttling in Single Table Design applications. Covers partition key design, write sharding, capacity modes, DAX caching, retry patterns, and CloudWatch monitoring for high-throughput systems.
When working with DynamoDB at scale, throttling becomes an inevitable challenge. The ProvisionedThroughputExceededException error often appears despite having adequate table-level capacity, and understanding why requires diving into DynamoDB's internal mechanics.
This guide covers proven patterns for preventing and handling throttling in Single Table Design applications, from partition key strategies to monitoring configurations that catch issues before they impact users.
Understanding DynamoDB's Throttling Mechanism
DynamoDB uses a token bucket algorithm for rate limiting. Each partition maintains its own bucket of read and write tokens that refill at a rate matching provisioned capacity. When tokens are depleted, requests get throttled.
The critical limits to remember:
Here's what makes this tricky: provisioned capacity is distributed across partitions. A table with 100 RCU and 3 partitions means each partition gets roughly 33 RCU. If one partition receives 80% of traffic, it will throttle even though the table has headroom.
Partition Key Design: The Foundation
Hot partitions cause most throttling issues. Getting partition key design right prevents problems that no amount of capacity can solve.
Anti-Patterns to Avoid
High-Cardinality Patterns That Work
Write Sharding: Distributing Hot Keys
When business requirements force low-cardinality access patterns, write sharding distributes load across multiple partitions.
Random Suffix Sharding
Best for write-heavy patterns where read aggregation is acceptable:
Deterministic Sharding
When you need to read specific items without scatter-gather:
GSI Write Sharding
Apply the same pattern to Global Secondary Indexes to prevent GSI throttling from blocking base table writes:
Warning: GSI throttling causes backpressure to base table writes. If your GSI cannot keep up with base table write velocity, all writes fail. Always match GSI capacity to base table needs.
Capacity Mode Selection
On-Demand Mode: Understanding the Limits
On-demand capacity has scaling constraints that catch teams off guard:
For traffic spikes, this 2x limit matters. A flash sale with 10x normal traffic cannot be handled immediately by on-demand. The table needs to "warm up" gradually or use pre-provisioned capacity.
Provisioned with Auto-Scaling
For predictable workloads with cost sensitivity:
Decision Framework
Burst and Adaptive Capacity
DynamoDB provides two automatic mechanisms that help with uneven traffic patterns.
Burst Capacity
Unused capacity accumulates for up to 5 minutes and can be consumed during traffic spikes:
Adaptive Capacity and Split-for-Heat
DynamoDB automatically rebalances capacity toward hot partitions and can split them when needed:
Note: Adaptive capacity rebalancing is instant (since May 2019), but split-for-heat (partition splitting) takes several minutes. For flash sale scenarios or viral content, a single hot partition key cannot be helped by either mechanism. Design partition keys properly rather than relying on adaptive capacity.
DAX for Read-Heavy Workloads
DynamoDB Accelerator (DAX) offloads read traffic from DynamoDB, reducing both latency and capacity consumption.
Note: The DAX SDK for JavaScript v3 (
@amazon-dax-sdk/lib-dax) was released in March 2025. It uses aggregated methods (.get(),.query()) instead of the.send()pattern used by the standard DynamoDB SDK v3.
When DAX Makes Sense
TTL Strategy by Data Type
Retry Strategies and Circuit Breakers
Handling throttling gracefully requires proper retry logic. The AWS SDK provides built-in retries, but batch operations need additional handling.
SDK Configuration
Batch Operations: Handling Unprocessed Items
The SDK does NOT automatically retry unprocessed items from batch operations:
Circuit Breaker for Sustained Throttling
When throttling persists, a circuit breaker prevents retry storms:
Client-Side Rate Limiting
Proactively limiting request rates prevents throttling from occurring:
CloudWatch Monitoring and Alerting
Proper monitoring catches throttling before it impacts users.
Key Metrics
CDK Alarm Configuration
Contributor Insights for Hot Key Detection
Enable Contributor Insights to identify which partition keys are causing throttling:
Common Pitfalls and Solutions
Pitfall 1: Relying on Adaptive Capacity
Pitfall 2: Ignoring GSI Capacity
Pitfall 3: On-Demand Scaling Assumptions
Pitfall 4: Missing Batch Retry Logic
Pitfall 5: Not Monitoring Per-Partition Metrics
Key Takeaways
- Design Partition Keys First: Hot partitions cause 90% of throttling issues
- Understand Per-Partition Limits: 3,000 RCU / 1,000 WCU per partition is the real constraint
- Write Sharding Works: 10 shards = 10x write throughput for same access pattern
- Adaptive Capacity Has Limits: Rebalancing is instant, but split-for-heat takes minutes; neither helps single hot keys
- On-Demand Has Limits: 2x scaling within 30 minutes, not unlimited
- GSI Throttling Blocks Writes: Capacity matching is essential
- DAX Needs High Hit Rate: Below 80% cache hit rate, ROI is negative
- Monitor Contributor Insights: Only way to identify hot keys in Single Table Design
- Retry Unprocessed Items: SDK does not auto-retry batch operation failures
- Pre-warm for Events: Both provisioned and on-demand need preparation for traffic spikes
Building throttle-resistant DynamoDB applications requires understanding these mechanics and implementing appropriate patterns at each layer. Start with partition key design, add sharding where needed, implement proper retries, and monitor aggressively. The result is a system that scales predictably without unexpected throttling incidents.
References
- docs.aws.amazon.com - Amazon DynamoDB Developer Guide.
- docs.aws.amazon.com - AWS documentation home (service guides and API references).
- docs.aws.amazon.com - AWS Well-Architected Framework overview.
- web.dev - web.dev performance guidance (Core Web Vitals).
- typescriptlang.org - TypeScript Handbook and language reference.
- github.com - TypeScript project wiki (FAQ and design notes).
- opentelemetry.io - OpenTelemetry documentation (metrics, traces, logs).
- docs.aws.amazon.com - AWS Overview (official whitepaper).
- cloud.google.com - Google Cloud documentation.