Consulta la tabla comparativa que aparece a continuación para decidir qué política debes usar en tu caso práctico de limitación de frecuencia:
Cuota
SpikeArrest
Úselo para:
Limita el número de llamadas a proxies de API que puede hacer una aplicación o un desarrollador durante un periodo específico. La política SpikeArrest es más adecuada para limitar la frecuencia en intervalos de tiempo más cortos, como segundos o minutos. Usa Cuota si necesitas que el recuento sea preciso.
Limita el número de llamadas a la API que se pueden hacer en un proxy de API en todos los consumidores durante un periodo específico (normalmente corto). La política de cuota 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 de tu proxy de API frente a picos de tráfico.
Para ello, usa la política SpikeArrest.
No la uses para contar y limitar el número de conexiones que las aplicaciones pueden establecer con el backend de destino de tu proxy de API durante un periodo específico. Nota: En los casos prácticos que requieran un recuento preciso, usa la política de cuota.
¿Almacena un recuento?
Sí
No
Prácticas recomendadas para adjuntar la política:
Adjúntalo al PreFlow de la solicitud ProxyEndpoint, normalmente después de la autenticación del usuario.
De esta forma, la política puede comprobar el contador de cuota en el punto de entrada de tu proxy de API.
Adjúntala al PreFlow de solicitud de ProxyEndpoint, normalmente al principio del flujo.
De esta forma, se proporciona protección contra picos en el punto de entrada de tu proxy de API.
Código de estado HTTP cuando se ha alcanzado el límite:
429 (servicio no disponible)
429 (servicio no disponible)
Información útil:
El contador de cuota se almacena en Cassandra.
Configura la política para sincronizar el contador de forma asíncrona y ahorrar recursos.
La sincronización asíncrona de contadores puede provocar un retraso en la respuesta de limitación de la frecuencia, lo que puede permitir que se realicen llamadas que superen ligeramente el límite que hayas definido.
Te permite elegir entre un algoritmo de "suavizado" o un algoritmo de recuento efectivo. La primera suaviza el número de solicitudes que se pueden producir en un periodo de tiempo especificado, mientras que la segunda limita el número total de solicitudes que se pueden producir en un periodo de tiempo especificado, independientemente de la rapidez con la que se envíen sucesivamente. Además, el suavizado no se coordina entre los procesadores de mensajes.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-11 (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."]]
