Comparing Quota and SpikeArrest policies

This page applies to Apigee and Apigee hybrid.

View Apigee Edge documentation.

Key Point: The Quota and SpikeArrest policies both count requests and take action if a specified request threshold is exceeded. Be aware, however, that the mechanisms by which these policies count requests are not the same.

While SpikeArrest maintains counts with high reliability, it is designed to use a Redis best-effort cache to store its counts. Because the cache is not replicated, there are cases where counts may be lost, such as a restart of the cache servers, or other rare cases.

For these reasons, we recommend against using SpikeArrest for use cases that require accurate counting. Only the synchronous Quota policy offers accurate counting across all regions in a given timeframe.

Use the comparison chart below to help you decide which policy to use to for your rate limiting use case:

	Quota	SpikeArrest
Use it to:	Limit the number of API proxy calls a developer app or developer can make over a specific period of time. The SpikeArrest policy is better suited for rate limiting over shorter time intervals like seconds or minutes. Consider Quota if accurate counting is a requirement.	Limit the number of API calls that can be made against an API proxy across all consumers over a specific (typically short) period of time. The Quota policy is better suited for setting limits on longer time intervals like days, weeks, months, or years.
Don't use it to:	Don't use it to protect your API proxy's target backend against traffic spikes. For that, use the SpikeArrest policy.	Don't use it to count and limit the number of connections apps can make to your API proxy's target backend over a specific period of time. Note: For any use cases that require accurate counting, use the Quota policy.
Stores a count?	Yes	No
Best practices for attaching the policy:	Attach it to the ProxyEndpoint Request PreFlow, generally after the authentication of the user. This enables the policy to check the quota counter at the entry point of your API proxy.	Attach it to the ProxyEndpoint Request PreFlow, generally at the very beginning of the flow. This provides spike protection at the entry point of your API proxy.
HTTP status code when limit has been reached:	429 (Service Unavailable)	429 (Service Unavailable)
Good to know:	Quota counter is stored in Cassandra. Configure the policy to synchronize the counter asynchronously to save resources. Asynchronous counter synchronization may cause a delay in the rate limiting response, which may allow calls slightly in excess of the limit you've set.	Lets you choose between a "smoothing" algorithm or an effective count algorithm. The former smooths the number of requests that can occur in a specified period of time, and the latter limits the total number of requests that can occur within a specified time period, no matter how rapidly they are sent in succession. Also, smoothing is not coordinated across Message Processors.
Get more details:	Quota policy	SpikeArrest policy

Tip: You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:

• Creating reusable shared flows: Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.
• Chaining API proxies together: Specify that one proxy is the target endpoint of another, effectively connecting the two proxies in a proxy chain. Chaining proxies in this way can help you avoid a network hop, and so improve overall performance.