Implementing Rate Limit Policies

Report Inappropriate Content · 12-11-2018 12:59 PM

Hello,

I am trying to implement rate limiting for certain API Products that I plan on exposing to my customers. For instance, I have 3 Products with the same proxies.

Product A - 10 calls/min - 100 calls/month

Product B - 20 calls/min - 10,000 calls/month

Product C - 30 calls/min - 100,000 calls/month

However, there seems to be a slight disconnect between what I see in common API pricing models and the Apigee documentation. This could easily be down to my lack of understanding and hence this post. See Zendesk's or Slack's per minute rate limits. Now my questions (specifically around the calls/minute aspect):

(1) Are these per minute rate limits in place due to business considerations (i.e. a means to force customers to move higher)? Or are they meant to be means to protect backend systems from sudden traffic spikes?

(2) What Apigee policy is more suitable to achieve the above mentioned configuration (of 10, 20 and 30 calls/min) - Spike Arrest policy or Quotas? To me it seems Spike Arrest as there is a line here that mentions Quota is better suited for longer intervals such as days or months. Is this correct?

(3) If its spike arrest, does the policy have to be defined at a Product level? This way all API developers of a given tier are entitled to the same number of calls/minute.

(4) Can there ever be a situation where a quota can conflict with a spike arrest policy?

Please let me know.

Thanks

dchiesa1

(1) Are these per minute rate limits in place due to business considerations (i.e. a means to force customers to move higher)? Or are they meant to be means to protect backend systems from sudden traffic spikes?

I think the purpose of the limits is ... what you want them to be. Apigee doesn't prescribe the purpose; you do. But let me disagree with your premise: I don't think business considerations always implies an enticement or lever to "force" people to move higher. Suppose you have different levels of technical vetting... A lower-tier partner would get 1000 calls / hour, where a higher-tiered partner (which went through deeper vetting) would get 10e6 calls per hour.

Protecting backend systems from spikes is not the intended purpose of the quota policy, but you could use it that way. Some people have the philosophy that... if they have an API, then ... why limit it at all? Imagine if you opened a physical store... under what conditions would you need or want to limit the number of customers walking in the door. Answer: you'd do that only to prevent a quality-of-service crisis based on too many people in the store. I suppose you could use the Quota policy for the analogous purpose.

(2) What Apigee policy is more suitable to achieve the above mentioned configuration (of 10, 20 and 30 calls/min) - Spike Arrest policy or Quotas?

Quota. But 10 calls/minute seems pretty low. Maybe you have special requirements.

(3) If the answer is spike arrest, ...

N/A

(4) Can there ever be a situation where a quota can conflict with a spike arrest policy?

No. I can't imagine what you mean by "conflict." You could design an API Proxy to daisy chain the two policies. But they would not conflict. If you were a sweater and an overcoat, will they conflict? No. Same here.

You did not ask, but... You could also design an API PRoxy to enforce more than a single Quota. There could be a per-min quota, a per-hour quota and a . per-day quota. All of them could be . independently enforced. They would not "conflict" but would complement each other to provide a more nuanced rate limit, if that's what you want.

Report Inappropriate Content

Hey Dino,

Thanks for the prompt response. Your answers have cleared up some of the doubts that I had. I do have a couple of follow up comments:

(1) The 10 calls/minute was an example. Its not reflective of the actual figure we'll be using.

(2) I see your point being able to use Quotas any way we see fit. I suppose another way of describing what you mentioned is use case. One customer's needs may be different from another and therefore you have different quotas for the different tiers. But let me elaborate on the question of conflict between spike and quota. Based on your recommendation, I'll be defining per minute quotas for my 3 API Products. But let's say the proxy that's in those API products has a spike arrest policy defined (30 requests/minute). That translates to 1 request every 2 seconds. Now if I get a 100 customers for my Product all making a call at once, couldn't there easily be a situation where the customers could violate the spike arrest policy (while being well within their quotas)?

dchiesa1

couldn't there easily be a situation where the customers could violate the spike arrest policy (while being well within their quotas)?

YES! Absolutely. The policy types are independent. A SpikeArrest may trip even if the customer is within Quota. That is by design. They are designed for different purposes, and so if you employ them both, you will want them to execute independently - that is to say, one policy must execute without regard for the configuration of the other policy.

If you use them both, You need to be mindful of the limits you define. Set them thoughtfully, in a way that avoids or minimizes surprises for the users and apps that are calling your APIs.