Rate Limit

Rate limiting is a great way to protect your API Keys from abuse. It allows you to restrict the number of requests that can be made to your endpoints in a given time frame.

You can enable the rate limiter for any project by going into the Security section.

Algorithms

We provide different algorithms to use out of the box. Each has pros and cons.

Fixed Window

This algorithm divides time into fixed durations or windows. For example, consider a window that is 10 seconds long. When a new request comes in, the algorithm determines the current window based on the current time (e.g., the 10-second window that includes the current time). A counter for this window is then incremented to reflect the new request. If the counter exceeds the predefined limit for that window, the request is rejected.

Pros

• Very cheap in terms of data size and computation
• Newer requests are not starved due to a high burst in the past

Cons

• Can cause high bursts at the window boundaries to leak through
• Causes request stampedes if many users are trying to access your server, whenever a new window begins

Sliding Window

This approach builds on the fixed window algorithm, but instead of resetting every time the window duration expires, it uses a rolling window. For example, consider a rate limit of 10 requests per minute. Time is divided into 1-minute slices, similar to the fixed window algorithm. Window 1 spans from 00:00:00 to 00:01:00 (HH:MM:SS).

Now, assume the current time is 00:01:15. In this scenario, 4 requests were received in the first window, and 5 requests have been received so far in the current window. The approximation to determine if the request should be allowed works as follows:

limit = 10
 
// 4 request from the old window, weighted + requests in current window
rate = 4 * ((60 - 15) / 60) + 5 = 8
 
return rate < limit // True means we should allow the request

Pros

• Solves the issue near boundary from fixed window.

Cons

• More expensive in terms of storage and computation
• Is only an approximation, because it assumes a uniform request flow in the previous window, but this is fine in most cases