How does Amazon DynamoDB handle spiky loads in short intervals?

Resolution

When you use provisioned mode, DynamoDB provides a degree of flexibility in your per-partition throughput provisioning by providing burst capacity. DynamoDB currently retains up to 5 minutes (300 seconds) of unused read and write capacity. Suppose that a DynamoDB table has its capacity provisioned at 150 RCUs and has no usage in the last 5 minutes. For this configuration, the table has 45,000 read units of burst capacity (150 * 300). Therefore, if a sudden spiky load pushes consumption to 200 read units, then DynamoDB can leverage burst capacity to accommodate 200 RCUs for 15 minutes.

Example: 45,000 / (200 - 150) = 900 seconds = 15 minutes

However, consider the following:

• Burst capacity is provided on a best effort’s basis and isn't guaranteed. Therefore, don't consider the burst capacity when you configure a table's provisioned capacity.
• DynamoDB might consume the burst capacity for background maintenance and other tasks without prior notice.
• Burst capacity can't alleviate partition-level throttling. A partition key that doesn't have a high cardinality can result in many requests that target just a few partitions. If a resulting hot partition exceeds the per partition limits of 3,000 RCU or 1,000 WCU per second, or a combination of both, your table throttles.

For more information, see Using burst capacity effectively. 

In on-demand capacity mode, DynamoDB automatically adapts to your application's traffic volume. On-demand capacity mode instantly accommodates up to double the previous peak traffic on a table. Suppose that your application's traffic pattern varies between 25,000 and 50,000 consistent reads per second and 50,000 reads per second is the previous traffic peak. In this case, the on-demand capacity mode instantly accommodates sustained traffic of up to 100,000 reads per second. If your application sustains the traffic of 100,000 reads per second, then that peak becomes your new previous peak. With this new peak, subsequent traffic might reach up to 200,000 reads per second.

However, if your spikes are nearly immediate and more than double the previous peak, your table might throttle. For more information, see Read/write capacity mode.