Quotas based off of custom criteria?

Most of the documentation I have seen on quotas presumes that what ticks the counter underlying the quota is an API call. I was wondering if there was a way to tick the counter in another way, e.g., certain calls which are more intensive counting more against a quota, or using something in the response to determine how much the quota would be affected, or even calling an API against a quota ticker inside of a backend. Are any of these possible?

Solved Solved
0 2 194
1 ACCEPTED SOLUTION

The quota policy contains a MessageWeight element that allows you to accomplish this. Quotas are enforced on the ProxyRequest flow, not on the TargetResponse flow though, so it is difficult to see how one could set the weight based on elements in the TargetResponse. However MessageWeight can use a ref= referenced value, so you could compute the weight using any number of criteria via a preceding policy, set that weight as a flow variable, and the weight value would be assigned using the ref variable.

View solution in original post

2 REPLIES 2

The quota policy contains a MessageWeight element that allows you to accomplish this. Quotas are enforced on the ProxyRequest flow, not on the TargetResponse flow though, so it is difficult to see how one could set the weight based on elements in the TargetResponse. However MessageWeight can use a ref= referenced value, so you could compute the weight using any number of criteria via a preceding policy, set that weight as a flow variable, and the weight value would be assigned using the ref variable.

yes that's right. 

All of the scenarios you describe in your original post are possible

You could use a ServiceCallout to invoke an endpoint to get the "cost" of a transaction and use that within the MessageWeight parameter of the Quota policy.  A good use of this is 

BigQuery is the backend upstream system, while the BigQuery job.info endpoint tells us what the query "costs".

In that case, you can configure the API proxy to use Bigquery.googleapis.com as the target, then invoke a ServiceCallout to the job.info endpoint, then extract the totalSlotMs , and use THAT as the MessageWeight. You could even apply some function to that totalSlotMs before applying it as the MessageWeight. For example during "busy hours" it could be 2x, while off-hours it might be 1x.  

What's more, you can even have the Quota LIMIT be dynamic, even after you've started counting.  For example the limit might start at 500 but due to heavier load you might want to lower it to 200. Of course you need an eternal endpoint that returns a "score" representing the busy-ness of the system, in order to enforce a dynamic quota. But if you have that, then you can use the Apigee Quota policy to enforce it. 

 

It's pretty flexible.