How to restrict the no of calls like only 1 request per ApiKey for an API at a time?

Not applicable

I have a requirement like only one call can be made to an API at a time using an API key. So when the first call using apiKey1 is being processed, second call using apiKey1 should be rejected. At the same time, if a call to the same api using apiKey2 is received, it should be allowed.

I am not sure if we can use Concurrent Rate Limit with an Identifier that used ApiKey would fulfill this requirement or a different policy should be engaged. Can someone suggest?

0 6 621
6 REPLIES 6

@Vidya

Any reason you would like to do same ? Why do you want to expiry an API Key for every single call ? It's almost like saying App can make a single API call using a key. Concurrent Rate limit is definitely not the solution for your requirement. Just FYI, Concurrent Rate Limit is used to throttle connections to backend. See 4MV4D that explains same here.

You need Quota Policy with a kind of token / key expiration. Bigger Question is why do you need it first ?

Hi Anil, The target is a Query API. As its a resource intensive API, we want to restrict parallel calls from the same client.

I had the same doubt of using the Concurrent Rate limit as its primarily used for throttling. However I have to use it to limit the total no of calls at a time, say 50, so only 50 clients can query the system at a time.

For enabling the API Key based restriction, do you recommend using a KVM or a cache to store a temporary flag against each API Key and restrict calls based on the flag?

@Vidya

Based on your explanation, It's concurrent rate limit policy. But, You requirement is interesting. Concurrent rate limit policy restricts number of parallel calls to the target. But, It doesn't support per identifier. You can say, restrict 5 parallel calls to the target, but, you can't say per app or per identifier.

KVM or Cache relies on Cassandra. In real time, You can't use it for keeping counters.

I am not sure at this point of time what will be right solution, I will keep you posted.

@Dino ^^ , Have you come across like this (concurrent rate limit per identifer) requirement ? What do you think about same ?

Not applicable

@Vidya,

So requirement is to have at the most one call from a specific API client. Same API client is eligible to make another call on completion of the earlier one.

Quota and Cache (having sufficient enough TTL) should work. Note that Quota need to be synchronous.

@Anil Sagar, @rdoda, I was able to implement my design successfully. I made use of LookUp cache, Populate Cache & Invalidate cache to maintain the Access Status of a call using an ApiKey. Of course, I used the apikey as the KeyFragment for CacheKey. Invalidate cache would be called on either success response or error response so the next call from the same apikey is not blocked.

Thanks for looking in & providing suggestions.