by Eugene Tolmachov (SherpaDesk IT Developer)

The Importance of Rate Limiting

There comes a moment in every IT entrepreneur's life when their app or website starts to gain traction, and they begin to see significant increases in traffic and API requests.

While some consider this to be a "Good Problem To Have," the reality is that API request spikes present a big challenge to your IT team. Handle it the wrong way, and your site or app could stop serving your customers the way it should.

The last thing IT entrepreneurs and small business owners want is to reach success by driving a lot of new traffic to their app or website, only to disappoint these hard-earned customers due to the inability to handle a large number of API requests. What can be done to prevent this? Enter rate-limiting your API.

Rate Limiting: Our Case Study

For the last three months, we experienced an exponential increase in the number of requests coming into our SherpaDesk API.

As API developers, we need to make sure that our APIs are running as efficiently as possible by enabling rate-limiting (in a smart way).

Otherwise, everyone on our database could suffer from slow performance. See Twitter's post on rate limiting for a more technical explanation on rate limiting.

But improving performance isn’t the only reason to limit API requests. Rate-limiting is an essential component of internet security because something like a DoS attack can tank your servers with unlimited API requests.

Rate-limiting can also help make your API scalable. So that if your website or app blows up in popularity and there's a spike in API requests traffic it will help prevent increases in lag time.

In this article, we’ll explain what limits we've imposed on SherpaDesk's API and how to build effective strategies around rate limiting.

 

Best practices to use SherpaDesk’s API (to avoid timeouts and 429 responses)

We recommend the following practices for the best experience and to reduce interruptions.

 

Monitor API Activity Against Your Rate Limit

You can also use the following response headers to confirm the account's current rate limit.

This header indicates your current server load:

X-Highdtu-Mode: 5

If our server is under heavy load, it will return a 5. If it's experiencing an above-average load, it will return a 2. When receiving a normal load, this header is empty or nonexistent.

This header indicates the number of milliseconds remaining for the next request.

X-Wait: 3000

We calculate this delay with this formula:

If single item: X-Highdtu-Mode *1 = 1 - 5 Seconds
if group of items: X-Highdtu-Mode * 5 = 5 – 25 seconds

 

Catching Errors Caused By Rate-Limiting

After each request, you can check to see if you've bumped into the rate limit. If you get a response code of 429, or "Too Many Requests," it means that you've hit the rate limit.

It's best practice to include code in your script that catches 429 responses. If your script ignores the "Too Many Requests" error and keeps trying to make requests, you might start getting null items.

 

Reducing the number of API requests

Make sure you make only the requests that you need. Here are some areas to explore for reducing the number of API requests:

1- Optimize your code to eliminate any unnecessary API calls.

2- Cache frequently used data.
You can also save relatively static information in a database or serialize it in a file.

3- If you need to backfill data, it is best to do so during non-peak business hours. Also, consider using our CSV exports, which are currently in beta.