AWS API throttling – fixing the throttling concern for Amazon Chime textual content chat

“Too many requests! You could have made too many requests!! No extra requests!!!” – What number of instances do it’s a must to hear that earlier than you get actually indignant? Amazon Chime API’s request throttling examined our persistence like this. However all we ever needed was to make a easy textual content chat app work! On this article, you’ll discover out why Chime was so unkind to us, what we did to show issues round, and the way you can also observe the trail we solid.

Request throttling is just not at all times on the forefront of the discussions about Amazon Internet Companies inc companies and instruments as it’s hardly ever a significant trigger for concern when creating a cloud-based system. Normally, each enterprise and growth focus extra on the quantity of reminiscence and storage they will use.

Nevertheless, in a current undertaking of mine, the difficulty of request throttling on AWS turned one among our most extreme bottlenecks, turning the seemingly easy job of including a textual content chat characteristic into fairly a fancy resolution filled with inventive workarounds. 

How did my crew and I discover a manner round request throttling to save lots of a high traffic textual content chat software? 

You’ll discover the reply on this sensible case research.

Background – what sort of textual content chat did the consumer want?

To make the matter clear, I must let you know a factor or two concerning the consumer I set to work for.

The consumer

The COVID pandemic triggered every kind of troubles and thwarted lots of plans of each people and firms. Plenty of folks missed out on vital gatherings, vacation journeys, and household time, to not point out long-awaited concert events, workshops, artwork exhibits, and dwell theatre occasions. 

Certainly one of my purchasers got here up with an answer – an on-line streaming platform that allows artists to prepare and conduct their occasions remotely for the enjoyment of their paying followers. Primarily, it made it attainable to convey an enormous a part of the dwell expertise to the online. It additionally opened up new alternatives in a post-COVID world, making artwork extra accessible to many individuals, anyplace they could be.

The consumer observed that performing with no public to take a look at and work together with may get sort of awkward for artists. To supply a manner for performers and followers to work together, we determined to equip the platform with a textual content chat.

The speculation – what’s throttling all about?

Earlier than we get to the app, let’s overview the idea behind the request throttling restrict. 

As you in all probability know, throttling is the method of limiting the variety of requests you (or your approved developer) can undergo a given operation in a given period of time.

A request may be whenever you submit a listing feed or whenever you make an order report request.

The time period „API Request Throttling” used all through this text refers to a quota put by an API proprietor on the variety of requests a specific person could make in a sure interval (throttling limits).

That manner, you retain the quantity of workload put in your companies in verify, making certain that extra customers can benefit from the system on the similar time. In spite of everything, it is very important share, isn’t it?

What about request throttling on the AWS cloud?

In my view, the documentation of EC2, probably the most fashionable AWS companies, has fairly a satisfying reply:

Amazon EC2 throttles EC2 API requests per account on a per-Area foundation. The aim right here is to enhance the efficiency of the service and guarantee honest utilization for all Amazon EC2 prospects. Throttling makes positive that calls to the Amazon EC2 API don’t exceed the utmost allowed API request limits.

Every AWS service has its personal guidelines defining the variety of requests one could make.

Problem – not your common textual content chat

Once you learn the title, you may need thought to your self: “A textual content chat? What’s so tough about that?”.

Properly, as any senior developer would let you know, absolutely anything may be tough – relying on the surface components.

And it simply so occurs that this exterior issue was particular.

Not your common, on a regular basis textual content chat

For the longest time, the AWS-based infrastructure of the platform had no points with throttling. It began displaying up throughout the textual content chat implementation of the Amazon Chime communications service.

In a typical chat app, you give customers the power to register and select chat channels they want to be a part of. Ours labored a bit in a different way.

On this one, every chat participant was to be distinguished by the exact same ticket code they used to achieve entry to the net occasion stream.

Sadly, the ticket information downloaded from our consumer’s ticketing system didn’t enable us to inform if a specific ticket belonged to a returning person. Due to that, we couldn’t assign earlier chat person accounts to the ticket. Consequently, we needed to create them from scratch for every occasion.

Decelerate there, cowboy!

Proper after downloading over a thousand tickets price of information from our consumer’s system, we tried to create Chime sources for all of them. 

Nearly instantly, we had been reduce off by the throttling error message as a result of excessive load, far exceeding the allowed most variety of 10 requests per second. We’ve encountered the identical drawback of most capability when making an attempt to delete sources after they had been now not wanted.

All of our issues stemmed from the truth that we didn’t instantly confirm the variety of requests we will make to the Amazon Chime API.

Sluggish and regular wins the race?

„What about utilizing bulk strategies?”, you may ask. Properly, on the time of writing this text there weren’t a lot of these obtainable.

Out of the 8 batch operations listed within the Amazon Chime API reference, we ended up utilizing just one – the power to create a number of channel memberships (with a restrict of 100 memberships created at a time).

Even checklist operations are restricted to fetching 50 gadgets at a time, which made it troublesome for us to maintain up with the bounds regarding the variety of customers the chat resolution would deal with.

At this level, we determined to attempt to create every person individually.

The answer to request throttling for Amazon Chime

Clearly, we needed to regulate our expectations relating to the velocity at which this course of would function. 

At 10 requests per second, we may create nearly the identical variety of customers (together with transient breaks for creating channels, moderators, batch memberships, and so forth). Fortunately, our consumer was wonderful with ready a bit extra. 

Each occasion was arrange upfront, giving our resolution sufficient time to create all the pieces earlier than the occasion even begins.

We additionally needed to make sure that for every ticket just one person can be created since Chime restricts the variety of these as nicely.

Our resolution was to arrange a separate EC2 occasion, which created Chime sources asynchronously to the method of organising an occasion and downloading tickets, limiting the consumer’s name rely.

AWS API throttling resolution – implementation

To start with, the setup features a CRON job scheduled to run each minute. 

This job has built-in safety from operating twice if the earlier job didn’t end in time. One other layer of safety from operating a job twice is having it run on a single EC2 occasion, with out upwards scalability.

Working createChimeUsers technique retrieves a set quantity of tickets from a non-public database (150-200 labored finest for us).

And for every ticket we retrieved from our database, we’re making a chat person.

We’ve used a package deal referred to as throttled-queue as our throttling handler.

The throttledQueue parameters are answerable for the next configuration of Chime API calls:

  • variety of most requests we wish to carry out per given period of time,
  • time (in milliseconds) throughout which quite a lot of requests as much as a most shall be carried out,
  • boolean flag figuring out whether or not requests must be unfold out evenly in time (true) or ought to run as quickly as attainable (false).

Within the given instance, adhering to Amazon Chime limitations, we’re making 10 calls per second, evenly unfold out all through this time.

You need extra AWS insights? Discover out about our developer’s expertise with API Gateway, together with API Gateway console, REST API, auto scaling, burst restrict, and extra.

Mission deliverables

So what did we obtain on account of doing all that?


So far as tangible deliverables go, we achieved the next:

  1. Service duties have been cut up. Consequently, the separation of issues for textual content chat and ticket retrieval has been achieved.
  2. The ticket retrieval system doesn’t concern itself with textual content chat anymore. Consequently, throttling or another AWS-related points don’t impression this perform anymore.
  3. The brand new textual content chat service handles the entire requests to Amazon Chime. Extracting this from a scalable service to a non-scalable one ensures that no duplicates of Chime sources shall be created.

What’s even higher, our success made a noticeable distinction for the product itself!


Now, that the request throttling concern has been resolved:

  1. A clean chatting expertise for finish customers has been achieved. There have been no detected points when it comes to lacking chat customers or inaccessible chat. 
  2. Performers can work together with the viewers undisturbed by technical limitations.
  3. With the present configuration, we’re in a position to create 9000 (!) chat customers per hour.
Fixing the throttling concern introduced enterprise advantages to the consumer

As you may see, discovering the customized manner round Chime’s request throttling resulted in lots of tangible advantages for the consumer, with out having to search for a completely new textual content chat resolution.

Textual content chat & request throttling points on AWS – classes realized

And that’s how my crew and I managed to work across the concern of AWS API throttiling in Amazon Chime, scoring a few wins for the purchasers within the course of.

The problem taught us, or ought to I say – reminded us of some classes:

  • Regardless of providing lots of advantages for the effectivity and stability of your infrastructure, AWS is not only a present that retains on giving. It’s very important to keep in mind that all AWS customers have the accountability to observe all the foundations in order that sources are shared pretty.
  • Earlier than you select a specific AWS service, it’s best to take note of all the bounds relating to effectivity, safety, request dealing with, and others set by the supplier.
  • Within the case of cloud-based architectures, growing the effectivity (that’s, the variety of requests per second) could also be both not possible or very pricey. That you must concentrate on what you are able to do along with your cloud service on the design stage to be able to keep away from issues in a while.

In the event you can observe these tips, you shouldn’t come throughout any surprises throughout the implementation of a textual content chat or another app or performance.

Do you need to work on AWS circumstances like this with us?

The Software program Home supplies a number of such alternatives for formidable builders that love difficult cloud initiatives.

Łukasz Brzeziński

Łukasz Brzeziński

Node.js developer

Skilled backend developer specialised in Node.js. He’s an enormous fan of long-distance operating and video video games, for which he sadly has much less and fewer time as years go by.


Leave a Reply

Your email address will not be published.