We would like to implement Rate-limit in API Proxy using spike arrest and Quota policy

Hi Team,

We would like to implement Rate-limit in API Proxy using spike arrest and Quota policy.

We already understood both policies nature and working process.

Prior recommending to API providers. Below are the things would like to know.

  1. What are the cases we could use both Spike Arrest and Quota policy in API Proxy flow.
  2. If we use both policies in API Proxy flow, which policy we need to keep first in order.

Thank you

Rajesh Nimmada

Solved Solved
0 7 889
1 ACCEPTED SOLUTION

Not applicable

This is a common query.

1. Yes, many api designers use both spike arrest and quota in their proxy. I also have implemented same in lot of APIs in multiple organisations. As the purpose they work are different, you can use both.

2. It's preferred to use spike arrest first and then quota. Still there is no rule like this. You can use spike arrest in the target endpoint also if you have multiple targets of different load strengths.

As quota is used for business purpose, I normally prefer if my backend cannot handle load then the user shuld not loose his quota counts. So, I suggest to use spike arrest first and quota next.

View solution in original post

7 REPLIES 7

Not applicable

This is a common query.

1. Yes, many api designers use both spike arrest and quota in their proxy. I also have implemented same in lot of APIs in multiple organisations. As the purpose they work are different, you can use both.

2. It's preferred to use spike arrest first and then quota. Still there is no rule like this. You can use spike arrest in the target endpoint also if you have multiple targets of different load strengths.

As quota is used for business purpose, I normally prefer if my backend cannot handle load then the user shuld not loose his quota counts. So, I suggest to use spike arrest first and quota next.

Do you know how to implement multiple quota limits in a single product

To add to the other answer:

  1. Quota is generally used for provisioning "tier usage" for your api consumers while SpikeArrest is used for protecting DDOS attacks (i.e. flatten spikes in requests loads). Ref: https://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-...
  2. Since SpikeArrest is mainly targetted at "unintended" users, when used for preventing DDOS attacks it is recommended to add it before Quota. In fact the recommendation would be to add it in a shared flow and invoke it across all API proxies via the Pre-Proxy Flow Hook.

FYI: We cannot use concurrent rate-limit policy as per APIGEE it is going to be decommission on next year and I asked how to implement multiple quota limits in a single product

yes, But I would like to know how to implement multiple quota limits in a single product.

Example : I have three applications subscribing a single product, now I am trying to provide separate quota limits to each application individually.

FYI: We cannot use concurrent rate-limit policy as per APIGEE it is going to be decommission on next year

Products make it easier to assign different attributes (eg: allocated quota) to the same APIs. In your example, I'd actually define 3 different products.

If, however, you prefer to go ahead and allocate quotas per client, I'd add custom attributes to the app storing the quota limits (Allow, TimeUnit, Interval). The quota policy would then need to reference these custom attributes when configuring the limits, and reference the clientId as the identifier.

Overall, more complicated than defining different products, but it also works.

Not applicable

For multiple quota policies in a single product, you have to use custom attributes in product and then use access entity policy to get the attribute values to implement in proxy.