Quota - Is there a way to apply a quota per developer app?

[raj-awasthi02]

Is there any way to achieve collective quota per developer app? for example "dev app1" has access to api1, api2 and api3. Can we set a collective quota for "dev app1" that is shared across api1, api2 and api3 it has access to?

[dchiesa1]

Yes, that's how it normally works.

The documentation for the Quota policy is pretty involved, because the Quota policy is pretty flexble. The thing you want is the the Identifier element. It can be used to specify the identifier for the Quota counter.

If you want each developer app to have its own counter, regardless of the various APIs the app uses, then you would use the context variable developer.app.id for the Identifier. (This is suggested in the documentation).

Keep in mind, this identifier is common across all instances of the app. Suppose you create a developer app, and then use the credentials associated to that app in a set of point-of-sale terminals. Let's say you have 250 POS terminals. If every one of those POS terminals embeds the same developer app identifier (also known as key, also known as credential), then the quota will be applied to the aggregate of requests across all of them.

Now suppose you set the request limit on the quota to be 1000 requests every 15 minutes. If one POS terminal submits 900 requests in the first 5 minutes, then ... The quota will allow only 100 additional requests in aggregate from the other 249 terminals, for the duration of the 15 minutes.

This behavior might be acceptable or even desirable if you have just 250 devices that you control. But if you have a mobile app, and the app is distributed to 1 million devices, then the aggregate quota will be applied in a way that may not allot requests fairly. In the extreme case, one rogue app or user could consume all of the quota and as a result "deny service" to the rest of the set.

If you wanted to enforce a quota on a specific INSTANCE of the developer app, then you might use the token value itself as the Quota identifier. Or, you could issue a distinct developer app credential for each instance of the app running in your system. Fortunately Apigee Edge supports this scenario - you can have a single app with lots of credentials associated to it. Or, you can configure multiple developer apps - 100's, 1000's even - that are authorized for the same API Product (or set of API PRoxies).

You can of course use other context variables as the Quota Identifier. If you wanted to enforce a quota specific to a combination of {developer app, API Proxy} then you can use a composite identifier. It would be enough to create a context variable that is the concatenation of developer.app.id with apiproxy.name.

[raj-awasthi02]

Thanks Dino for detailed answer, one quick cross check, after using <Identifier> element on client_id each developer app now have their individual quota, but the quota is still not shareable across multiple APIs to which developer app has access to, for example if developer app "dev-app1" has quota of 100/hour and has access to product P1 that has api1, api2 and api3. The "dev-app1" can basically make a 100 call to api1 and 100 call to api2 and 100 call to api3 with the given hour. What I am looking if dev-app1 makes 30 calls to api1 and 20 calls to api2 then only 50 calls should be allowed to api3 for given hour? Is this behavior possible?

[ranjithbabu-dar]

Did you got any solution for this use-case?

[dchiesa1]

Sorry, I had missed the followup question so long ago.

Yes, there is a solution.

Unfortunately today in Apigee, the "bucket identifier" that the Quota policy uses to collect counts, always implicitly includes the Proxy name and the policy name in the bucket identifier. That means if you have a developer app named "dev-app1" and you use the "developer.app" variable as the identifier in the Quota policy, implicitly the Quota policy will also compose the value of the developer.app context variable with the name of the apiproxy and the name of the policy itself. This is not what you want. There is a feature request to allow greater flexibility in the way identifiers are handled: b/149229963. I encourage you to escalate your desire for this capability to your Google Technical account manager or Customer Engineer.

In the absence of the greater flexibility you seek, you can work around the problem by calling out from your proxy to a "Local proxy" which is set up to only enforce the Quota. All API proxies as part of the same environment can call to that same Quota policy, and they can use the correct identifier. The Quota policy in the linked proxy will still append the Proxy name and the policy name to the quota identifier, but those values will be the same for all calls into that local proxy. Therefore you get the behavior you desire, at the expense of an additional "daisy-chained" call into the quota enforcing proxy.

This works and is in use in production systems at various customers who have the need to enforce a shared quota across APIs.