For ex: in wealth management, is there a way to allow an API call from a high networth individual as opposed to say someone like me when the traffic reaches a certain threshold.
~~S:G:TC~~
"Identifier" element can be used to uniquely identify a request and apply spike arrest accordingly. However, identifying request owner would require access token verification and that in turn will delay enforcing the SpikeArrest policy.
I would suggest to apply SpikeArrest as generically for a proxy as a protection against DDoS
Use quota policy with Identifier to provie more quota for such customer type and use custom attribute having quota value for different customer type.
I think what Anil is describing is a rate limit that applies "only when the traffic exceeds a certain threshold." Which I am translating to "only when there is contention."
Let's say there are A-class and C-class clients/users.
My understanding of the problem:
Depending on the exact requirement, I think you could do it. Maybe with a 2-stage quota enforcement, with some conditionals. Here's what I imagine:
In the DSL for Apigee Edge it might look like this:
<PreFlow name='PreFlow'> <Request> <Step> <Name>VerifyAccessToken-1</Name> </Step> <Step> <Condition>accesstoken.A-class = "true"</Condition> <Name>PopulateCache-SetContentionFlag</Name> </Step> <Step> <Condition>not (accesstoken.A-class = "true")</Condition> <Name>LookupCache-GetContentionFlag</Name> </Step> <Step> <Condition>not (accesstoken.A-class = "true") AND (contention = "true")</Condition> <Name>Quota-C-class</Name> </Step> <Step> <Name>Quota-1</Name> <!-- optional --> </Step> </Request> </PreFlow>
Depending on the exact requirements, that might satisfy. It's not "priority queueing". Instead it is "secondary quota enforcement only when contention occurs".
This is very naive, but it illustrates the idea. Probably, the "contention" state should be set not based on whether a single request has arrived, but based on whether the load or concurrency is "high". How would you determine that? For that you could use a non-enforced quota, a counter that is incremented for every request, but which does not ever return 429. You could simulate this by using a quota with a limit of 10e6 requests per minute.
When that quota policy executes, it will compute the counters, and set context variables like this:
ratelimit.{policy_name}.used.count
So the contention state might be based on that number, being above "a fixed threshold". Let's say, 1000 requests per minute.
The updated XML might be:
<PreFlow name='PreFlow'> <Request> <Step> <Name>VerifyAccessToken-1</Name> </Step> <Step> <Name>Quota-Unenforced-1</Name> <!-- eg, 10e6 / min --> </Step> <Step> <Condition>accesstoken.A-class = "true" AND (ratelimit.Quota-Unenforced-1.used.count > 1000) </Condition> <Name>PopulateCache-SetContentionFlag</Name> </Step> <Step> <Condition>not (accesstoken.A-class = "true")</Condition> <Name>LookupCache-GetContentionFlag</Name> </Step> <Step> <Condition>not (accesstoken.A-class = "true") AND (contention = "true")</Condition> <Name>Quota-C-class-DuringContention</Name> </Step> <Step> <Name>Quota-1</Name> <!-- optional --> </Step> </Request> </PreFlow>
Class-based Quota configuration may provide easy solution as this being based on customer types.
User | Count |
---|---|
5 | |
2 | |
1 | |
1 | |
1 |