Rate Limiting Per Consumer using Azure API management

Recently, we came across a situation in which we had to add consumers to one of our API and add rate limiting to it. This means that different consumers will be able to call our API at a different rate limit and beyond that rate limit our API will give 429 status code with a response containing the retry-after duration.

Below diagram explain the use case which we wanted to achieve:

Problem statement

We wanted to use some off-the-shelf solutions for this with minimum custom logic. We had our API exposed as a function app. In order to add Rate Limiting, we can use the Rate Limiting policy of Azure API management to rate limit requests based on a key.

If we simply use Rate Limit by Key at the API/Operation level that would have the same rate limit applied for all the consumers/subscribers (which we don’t need at all). What we wanted is to have a different rate limiting for different consumers.

The Solution

We came across a feature of APIM called Products, which can help you group your APIs and add rules on top of it.

We created 2 products and added policies on top of those 2 products to have different rate limits.

Now we have the products (having our API) ready, with the required policies. The next thing was to think about how to expose this product to consumers.
This is where subscription comes in handy, you can add subscriptions to your API/Product/Operations and give that subscription key to the consumer. Consumers will only get access to API/Product to which the subscription is tied.

The below diagram explains the high-level solution using API management (Rate limits are per minutes instead of seconds):

Solution: Different rate limits for different consumers

We created 2 subscriptions for the already created 2 products and handed over the subscription keys to the consumers.

This is how the updated architecture would look after adding API and rate limiting:

Updated Architecture

Following above steps we achieved different throttling limits for different consumers.

The same logic can be used to add Quota on top of your APIs. Rate limits protect against short intense volume bursts and usage quotas for longer duration access restrictions and tier-based monetization scenarios.

Post a comment if anyone needs more information about the low-level implementation details.

Happy Learning :)