When working with API and API testing and in System Desing, you may see these terms being used. Many times people use this interchangebly. However you need to understand that there is a difference. These two terms are very important in building a resisliant systems. It becomes particularly important when you’re exposing your API’s to some external systems or to public – like Google API’s , AWS etc.

Although both of these have slight differences- both of them work to serve the same purpose – “to control the amount of traffic to an API endpoint“.

API Throttling

API throttling is a technique used to control the amount of traffic that an API can handle and this is in most cases used in conjunction with Rate Limiting. API Throttling can be used to prevent overloading the server or the network the API is hosted on.

API throttling is generally enforced by the server, which the client has to respect. By limiting the amount of requests that the API can handle in a given time, the server ensures that the API is responsive.

Rate Limiting

Rate Limiting is a technique that is used to control the number of requests sent to the server by a client – particularly over a given period of time. Generally this is done so that the exposed API’s are not abused by the client.

You can either use the configuration given by the server for rate limiting or implement your own limit.


Let’s see the differences between the two bases on what purpose they have

PurposeThrottlingRate Limiting
Used for managing resourcesAt server or network levelAt client level
Main GoalIs to ensure that the API can handle the traffic it is recievingIs to ensure that the API is not abused, and the client is only able to hit the API within limits.
ImplementationImplemented by setting the limit on the
number of requests that can be made or processed by the API in a given time frame.
By setting the limit on the number and speed of requests that can be made by a client within a specific time period.
What happens after
limit gets exhausted
The API will not process any more requests until the time limit gets over, or the client pays to enable extra calls.No more requests can be made by the client in this case.

As you can see there is a fine line of difference between the two concepts. When testing public or even enterprise API’s , its always a good approach to include these concepts and test for these limits. These can unearth really underlying issues inside the system under test or API under test.

I’ll be back with a new topic tomorrow. Keep watching this space.