Usa el siguiente cuadro de comparación a fin de decidir qué política usar para tu caso de uso de límite de frecuencia:
Cuota
SpikeArrest
Puedes usarlo para lo siguiente:
Limita la cantidad de llamadas al proxy de API que una app o desarrollador puede realizar durante un período específico. La política de SpikeArrest es más adecuada para el límite de frecuencia en intervalos de tiempo más cortos, como segundos o minutos. Considera la política de cuotas si el recuento preciso es un requisito.
Limita la cantidad de llamadas a la API que se pueden realizar en un proxy de API en todos los consumidores durante un período específico (por lo general, corto). La política de cuotas es más adecuada para establecer límites en intervalos de tiempo más largos, como días, semanas, meses o años.
No lo uses para lo siguiente:
No la uses para proteger el backend de destino del proxy de API contra los aumentos de tráfico.
Para eso, usa la política SpikeArrest.
No lo uses para contar y limitar la cantidad de conexiones que las apps pueden realizar en el backend de destino del proxy de API durante un período específico. Nota: Para cualquier caso de uso que requiera un recuento preciso, usa la política de cuotas.
¿Almacena un recuento?
Sí
No
Prácticas recomendadas para adjuntar la política:
Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, después de la autenticación del usuario.
Esto permite que la política verifique el contador de cuotas en el punto de entrada del proxy de API.
Adjúntala al flujo previo de solicitudes de ProxyEndpoint, por lo general, al principio del flujo.
Esto proporciona protección contra los aumentos de tráfico en el punto de entrada del proxy de API.
Código de estado HTTP cuando se alcanza el límite:
429 Servicio no disponible
429 Servicio no disponible
Información útil:
El contador de cuotas se almacena en Cassandra.
Configura la política para sincronizar el contador de forma asíncrona con el fin de guardar recursos.
La sincronización asíncrona del contador puede causar un retraso en la respuesta del límite de frecuencia, lo que puede permitir que las llamadas superen apenas el límite que estableciste.
Te permite elegir entre un algoritmo de “suavizamiento” o un algoritmo de recuento eficaz. El primero reduce la cantidad de solicitudes que pueden ocurrir en un período especificado y el último limita la cantidad total de solicitudes que pueden ocurrir dentro de un período específico, sin importar qué tan rápido se envíen sucesivamente. Además, el suavizamiento no está coordinado en los Message Processors.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-09 (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."]]
