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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 UTC."],[[["\u003cp\u003eThis content focuses on the Quota and SpikeArrest policies within Apigee and Apigee hybrid, which are used to manage request thresholds.\u003c/p\u003e\n"],["\u003cp\u003eThe Quota policy is recommended for use cases requiring precise request counting over longer durations like days, weeks, months, or years, offering accurate counting across all regions.\u003c/p\u003e\n"],["\u003cp\u003eSpikeArrest is better suited for rate limiting over short intervals, such as seconds or minutes, and for protecting backend services from sudden traffic spikes, but its request counting may not be entirely accurate due to its use of a Redis cache.\u003c/p\u003e\n"],["\u003cp\u003eBoth the Quota and SpikeArrest policies trigger a \u003ccode\u003e429\u003c/code\u003e (Service Unavailable) HTTP status code when request limits are reached, indicating a temporary denial of service.\u003c/p\u003e\n"],["\u003cp\u003eShared flows and chaining proxies can be utilized to protect slower backends without impacting API performance.\u003c/p\u003e\n"]]],[],null,["# Comparing Quota and SpikeArrest policies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Key Point:** The [Quota](/apigee/docs/api-platform/reference/policies/quota-policy) and [SpikeArrest](/apigee/docs/api-platform/reference/policies/spike-arrest-policy) 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.\n|\n|\n| While SpikeArrest maintains counts with high reliability, it is designed to use a\n| [Redis\n| best-effort cache](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis) to store its counts. Because the cache is not replicated, there are cases where counts may be\n| lost, such as a restart of the cache servers, or other rare cases.\n|\n| For these reasons, we recommend\n| against using SpikeArrest for use cases that require accurate counting. Only the synchronous\n| Quota policy offers accurate counting across all regions in a given timeframe.\n\nUse the comparison chart below to help you decide which policy to use to\nfor your rate limiting use case:\n\n| **Tip:** You can also use the following to protect slow/sluggish backends without impacting the performance of the APIs:\n|\n| - [Creating reusable shared flows:](/apigee/docs/api-platform/fundamentals/shared-flows) Combine policies and resources into a shared flow that you can consume from multiple API proxies, and even from other shared flows.\n| - [Chaining API proxies together](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies): 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."]]
