Quota Policy / Rate Limits for Individual Users

Google Cloud Apigee
,
1

Following on from a similar topic raised here: https://www.googlecloudcommunity.com/gc/Apigee/How-to-validate-Quota-Policy-against-JWT

I’m considering a use-case in which we may want to apply quotas for individual users (either based on their access token, or more likely a unique user ID associated with their token(s)) to prevent abuse by individual authenticated users.

In this case applying a Quota Policy against the client_id wouldn’t be sufficiently granular as it would apply across all instances of a given developer app (for example the organisation’s Android app) and any quota exhaustion would affect all users using that developer app.

If we were to use an [Identifier](https://docs.apigee.com/api-platform/reference/policies/quota-policy#identifierelement) in a Quota Policy specific to a user, Apigee would need to maintain a significant number of individual counters for these quotas as have a large number of active users at peak. Are there any performance or cost implications we should be aware of when considering this?

For wider context, this is inspired by some of the approaches listed in this article used by Github, LinkedIn & Bitly to apply quotas for authenticated users: https://nordicapis.com/everything-you-need-to-know-about-api-rate-limiting/#bestpracticesforapiratelimiting

2

Yes, you can configure Apigee to enforce a quota that is specific to each user. You are correct that Apigee would then maintain a “large number” of individual counters (equal to the number of active users) for this quota enforcement, and there will be performance implications as a result of this.

Apigee has a backing store that is designed for high concurrency and high scale. You didn’t say how many individual users you expect to be active at any one time, so it’s hard for me to say if the stress on the system will result in poor performance for your users. I’d say if you expect o(10^4) active concurrent users, your system will probably perform well. If you expect to have o(10^5) or o(10^6) active users, you will need to test and evaluate, but probably the performance will be acceptable. If you have o(10^7) or more concurrent active users, we (the Apigee team at Google) will want to talk with you, collaborate with you, to work up a configuration that makes sense.