BETTER ORDER FOR SPIKE ARREST,QUOTA AND CONCURRENT POLICY?

IS THERE ANY ORDER FOR THESE POLICIES (SPIKE ARREST,QUOTA AND CONCURRENT POLICY) IN TERMS OF BETTER PERFORMANCE OR SECURITY ?

OR WHAT WILL BE THE BEST ORDER TO ADD THESE POLICIES?

@Anil Sagar

0 5 867
5 REPLIES 5

sidd-harth
Participant V

Hi @Arun Prasath Sivanesan, please have a look at this doc, which compares all three policies.

https://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-...

IMO security wise I would first control the number of calls made & then check if the user/developer quota & finally use concurrent rate limit.

Spike Arrest >> Quota on Proxyendpoint Preflow

Use Concurrent Rate Limit on Targetendpoint.

Note - Use of the Concurrent Rate Limit policy is known to impact performance and will result in lower throughputs.

@Siddharth Barahalikar , Agree with performance impact of Concurrent Rate Limit.

Regarding Order, What if quota is calculated, concurrent rate limit raises exception ? See my answer below, Let me know what you think !

You don't want to count the quota before this policy if concurrent rate limit raises exception.

Thanks, @Anil Sagar @ Google for pointing it out, I missed this point while answering. Now it makes sense why we need to use quota after concurrent policy.

So, in this case, we should be adding Quota on Target Endpoint Preflow after Concurrent Policy right?

If yes, then the proxy is going to execute all policies attached on Proxyendpoint Preflow >> ConditionalFlow >> PostFlow Requests and will check for Quota only on Targetendpoint Preflow after Concurrent Policy.

Is this one of the reasons why Concurrent Rate Limit policy is known to impact performance and will result in lower throughputs?

Great Question @Arun Prasath Sivanesan , Great Question,

Here is what i think about same in terms of order,

  • Spike Arrest - Fist Policy before any policy executes
    • You would like to detect DOS Attacks before you do anything. So, It should be your first policy in order.
  • Concurrent Rate Limit Policy
    • I think it makes sense to use before quota because, You don't want to count the quota before this policy if concurrent rate limit raises exception. Because, App Developer will end up consuming quota for an API that returns error.
    • I would prefer not to use this policy because of performance / business reasons. Instead, I opt for designing my quota intelligently to avoid target latencies.
    • At some point of time, You need to scale backends or cache API data in edge to be able to serve traffics. Why not start scaling backends instead of blocking traffic ?
  • Quota Policy
    • I will count quota after all the checks has been passed.

Hope it helps.

If I am not wrong, concurrent rate policy should be attached to target endpoint (also default fault rule) whereas spike arrest and quota should be attached to proxy end point. So I believe the first in the order should be spike arrest and then quota after eliminating concurrent from proxy endpoint.

correct me if I am wrong