What is the difference between the Rate Limit and Spike Arrest interceptors?
Both Rate Limit and Spike Arrest interceptors are used to control the number of requests accepted by an API, resource, or operation. However, they manage this control in different ways:
Rate Limit | Spike Arrest |
---|---|
Rate Limit works based on time intervals (second, minute, hour, day, month). It checks if the number of calls within the configured interval is within the expected limit, regardless of the time between calls. When the interval ends, a new one starts, and the call count is reset. |
Spike Arrest ensures a minimum time distance between two calls. If the time between two requests is not respected, the second request will not be accepted and will result in an HTTP 429 error. This mechanism prevents traffic spikes and protects the server, ensuring a manageable incoming flow. |
When to use each?
To ensure general limits, Rate Limit is the most suitable. It can also be used to reduce traffic spikes within seconds, but it is more effective for relatively spaced traffic. If your goal is to protect the server from overload and intense traffic, Spike Arrest offers better control.
How to configure them?
To configure the interceptors, it is important to understand the working logic of each. Since Spike Arrest works with intervals between calls, configuring it with a limit of 1 request per second, 60 per minute, or 3600 per hour will result in the same behavior, as the minimum interval will be the same.
Rate Limit requires more attention in configuration because it operates based on the total number of calls within a time frame. Thus, configuring a limit of 1 request per second is different from 60 per minute, as in the first case, the count is reset every second, and in the second, every minute. See the examples below for a better understanding.
Examples of use: Spike Arrest
-
Limit of 6 requests per minute: we have a Spike Arrest configured for 6 requests per minute, resulting in a minimum interval of 10 seconds between calls. Accepted calls are shown in purple and denied calls in orange:
Calls are only accepted if they are made regularly, with the minimum interval between them.
-
Limit of 1 request per second: Spike Arrest is configured for 1 request per second (equivalent to 60 per minute). We consider 100 requests made in 1 minute. Accepted calls are shown in purple and denied calls in orange:
In total, 45 of the 100 calls were accepted, respecting the interval between them and preventing traffic spikes, distributing calls more evenly.
Usage examples: Rate Limit
-
Limit of 1 request per second: Rate Limit is limited to 1 request per second. Accepted calls are shown in purple and denied calls in orange:
If calls exceed the configured limit within the defined interval, Rate Limit will serve a number of requests within the limit. This scenario is shown in the graph below, representing 1 minute of Rate Limit operation with 100 requests made.
In this case, Rate Limit served 55 of the 100 calls. This occurs because, unlike Spike Arrest, Rate Limit allows closely spaced calls as long as one occurs at the end of one window and the other at the beginning of the next.
-
Limit of 60 requests per minute: in this scenario, Rate Limit accepts up to 60 requests per minute. As the call count resets only at the end of the period, the operation is different from the previous configuration (1 request per second). Again, we represent 100 calls over 1 minute. As expected, Rate Limit accepted 60 requests:
Traffic spikes are allowed within the total call limit for the period. If the limit is reached, the API (or resource or operation) will be unavailable until the beginning of the next time window. In the example above, since the 60th request occurred just before the 33rd second, this unavailability would last for 27 seconds.
Share your suggestions with us!
Click here and then [+ Submit idea]