A brief overview of API rate limiting strategies
While creating APIs, we need to take into consideration various corner case scenarios. One such cases is handling redundant spam API requests, it is often noticed that in such cases, the server is overwhelmed with lots of API requests which slows down the server response and in turn affects the overall throughput. So in order to handle such situations, developers should always take some preventive measures like rate-limiting the APIs .
Rate limiting is a preventive measure in order to safeguard the servers from excessive unwanted API requests. In case of sudden surge in API requests, the server will be overwhelmed with lots requests and in case the server needs to query the database, then the database server will also be in turn under stress with lots of database transactions. In overall aspect, there will be a degradation of performance.
Rate limiting is applied in APIs so that a client can make certain specific number of API requests to the server in particular interval of time so it will restrict the chances of huge amount of unwanted spam requests that may in turn hamper the performance of the server
Different strategies for rate limiting
There are mainly 2 important strategies that one can follow while designing APIs for implementing rate limiting measure. These 2 strategies are Token Bucket Strategy and Leaky Bucket Strategy.
Token Bucket Strategy
According to this strategy, there are tokens 🪙 (kept in a so-called bucket 🪣 😄) which are required for making/performing an API requests. Since there are limited number of tokens (available in the bucket 🪣 ) , if there are no further tokens available , no further API requests can be served and the requests need to be queued until further tokens are available or else the request can be rejected.
Leaky Bucket Strategy
Just imagine the scenario that there is a leaky bucket under a running water tap. In that case, you might have noticed water is leaking slowly from the hole in the bucket, though water is filling from the tap at a comparatively faster rate. Now, just think of the same scenario for a web server. Here, the numerous API requests is like the running water from the tap. So, here the leaky bucket can help to control the surge of API requests and protects the server from too much pressure.
In this case, Leaky Bucket acts like a shock absorber for the server. All the requests passes through the Leaky bucket, so whenever there is a surge in requests, all the requests comes to bucket, but only few are passed on to the server at a controlled rate while keeping the others in waiting or rejecting after timed out.
