DynamoDB Throttling - Everything You Need To Know

Throttling is one of the most common limitations developers face when using DynamoDB. A throttled DynamoDB table can significantly impact the performance of your application and ultimately lead to loss of data. As developers, it is essential to have a good understanding of these limitations to prevent them.

So, in this article, I will discuss what DynamoDB throttling is, the reasons for DynamoDB throttling, and how to deal with throttling issues in DynamoDB to give you a better understanding.

What is DynamoDB Throttling?

DynamoDB tables consist of multiple partitions. Data records are distributed among the partitions based on the partition key generated by a hash function. Each partition can have an equal amount of Read Capacity Units (RCUs) and Write Capacity Units (WCUs) up to a maximum of 3000 RCUs and 1000 WCUs. These read and write capacities are equally distributed among each partition. For example, if the RCUs and WCUs are 50 and the table has 2 partitions, each partition will have 25 RCUs and WCUs.

• RCU (Read Capacity Units) - One strongly consistent read per second for an item up to 4 KB in size or two eventually consistent reads per second for an item up to 4 KB in size.
• WCU (Write Capacity Units) - One write item per second for item size up to 1 KB.

When a request is made to a DynamoDB table to read or write an item, the request will be routed to the relevant partition, and the read and write capacity of that partition will decide if the request is allowed or rejected. If the requests start getting rejected or slow, your DynamoDB table is throttling, and you need to take immediate actions to fix it.

In simple terms, DynamoDB throttling is the process of preventing or rejecting reads and writes to a DynamoDB table.

However, DynamoDB is a fully-managed database service. So then, why do we need to worry about throttling? Let's find out.

When Does DynamoDB Throttle Requests

When you create a DynamoDB table, it provides 2 options for capacity mode: provisioned and on-demand.

Provisioned model

In the provisioned model, we must manually configure all the auto-scaling options, including the minimum and the maximum number of capacity units. This is the most cost-effective capacity model and is most suitable when you have an understanding of the application traffic.

However, this model is more vulnerable to throttling issues since it is manually configured. Here are some of the most common reasons that cause throttling in provisioned models.

• Hot partitions - If a single partition of your table keep receiving more than the average number of request continuously, that partition can start throttling. This can happen when the cardinality of a partition key is low.
• Not enough capacity - When most of the partitions exceed the 3000 RCU and 1000 WCU capacity.
• Sudden increases in the traffic - Assume that you have provisioned 10 WCUs for a table. This allows the table to perform 600 writes per minute. But, if the table receives all 600 requests within 1 single second, throttling can happen.

On-demand model

If you choose the on-demand model, AWS will automatically scale your table's read and write capacities based on the workload. Compared to provisioned, this model is more expensive, but it is more suitable for unpredictable traffic.

When it comes to throttling, the on-demand model is more robust for failures since it automatically adapts to the application’s traffic. But, it does not prevent throttling 100%. Here are some of the most common reasons that cause throttling in on-demand models.

• Not enough capacity - When most of the partitions exceed the 3000 RCU and 1000 WCU.
• When traffic doubles the previous peak - If your DynamoDB traffic increases more than double the previous peak within 30 minutes, you might experience throttling.

What Happens When DynamoDB Is Throttled

As I mentioned, it is essential to identify the throttling behaviors on time and take the necessary steps to prevent them. If not, continuous throttling can cause serious issues to your application.

• Application performance will decrease due to the high number of retrying requests.
• Users will receive outdated data if only the write requests are throttled.
• The application can start losing data if it fails to retry the throttled write requests.

How To Deal With Throttling Issues in DynamoDB

The best way to deal with throttling is to allocate the necessary amount of WCUs and RCUs to partitions. Else, you can start with a small capacity and increase it based on the traffic by closely monitoring.

But, this approach might not be practical for every situation. As discussed earlier, throttling can happen for various reasons, and we need to address them based on the situation. So, let's consider some of the common reasons for throttling and discuss how to avoid them.

Hot partitions

Hot partitions can be caused due to low cardinality partition keys. In such situations, the request can exceed the capacity limit of these partitions, and they will start to throttle.

The best way to address hot partitions is to design the partition keys to distribute workload evenly. You can find more details about choosing the right DynamoDB partition keys in AWS documentation.

• Choosing the Right DynamoDB Partition Key.
• Designing Partition Keys to Distribute Your Workload Evenly.

You can also use diagnostic tools like Amazon CloudWatch Contributor Insights to monitor partition workloads.

Sudden increases in traffic

Sometimes, sudden traffic spikes can cause throttling even if you have the necessary capacity allocated. For example. If your DynamoDB table has an RCU of 100 requests, it can process 6000 write requests per minute. But receiving all 6000 requests within a single second would cause the table to throttle.

In such scenarios, you can add jitter and exponential backoff to your API calls to avoid throttling. Jitter and exponential backoff help to prevent failures by adding random time gaps between requests.

When traffic exceeds the per partition maximum

This is one of the common throttling issues you can face in both on-demand and provisioned models and is pretty similar to hot partitions. You can use the same methods to parent traffic exceeding the per partition maximum.

When traffic doubles the previous peak

Although the on-demand capacity model can adapt to the traffic, it can still cause throttling if the traffic gets double the previous peak within 30 minutes.

So, it is always good to ensure that traffic growth is spread across the partitions over 30 minutes, even if you are using the on-demand model.

Throttling while auto-scaling is enabled

Even if you are using the provisioned capacity mode, AWS enables auto-scaling. But, you need to be aware that auto-scaling does not resolve the throttling issues.

Auto-scaling works only when the consumed capacity exceeds target utilization for two consistent minutes. Similarly, a scale-down event is initiated when 15 consecutive data points for consumed capacity in CloudWatch are lower than the target utilization.

So, it can take a significant time to update the provisioned capacity, and that's why it is not suitable to handle spiked workloads in DynamoDB.