Pautas de rendimiento: consideraciones sobre límites de tasa y ráfaga

Límite de tasa

La API pública de Cobre admite 30 transacciones por segundo (TPS) en operación en estado estable. Para garantizar un rendimiento consistente y evitar errores HTTP 429 (Too Many Requests), recomendamos encarecidamente seguir estas buenas prácticas de API:

Implementar retroceso exponencial con lógica de reintentos.

Usar claves de idempotencia en todas las operaciones sensibles.

Evitar patrones de sondeo agresivos.

Optimizar la frecuencia de solicitudes y el procesamiento por lotes cuando aplique.

Apoyarse en Webhooks para actualizaciones asíncronas siempre que sea posible.

Un uso eficiente de la API ayuda a mantener baja latencia, alta confiabilidad y un comportamiento predecible, incluso bajo condiciones de tráfico pico.

Límite de ráfaga

Además del límite de tasa sostenido, la clave de API de cada cliente tiene un límite de ráfaga de 200 solicitudes, implementado mediante un algoritmo de cubo de tokens. Este cubo almacena hasta 200 tokens (uno por solicitud) y se recarga a una tasa de 30 tokens por segundo, equivalente al límite de tasa en estado estable.

Esto significa:

Esa capacidad de 200 solicitudes es un búfer de uso único, no un límite repetible por segundo. Una vez consumida, solo se recarga a 30 tokens/segundo, por lo que el tráfico sostenido por encima de 30 TPS agotará el cubo y eventualmente generará respuestas HTTP 429.

Por ejemplo: si envía 100 solicitudes en el primer segundo con el cubo lleno, las 100 tienen éxito y el cubo se recarga en 30 (quedando en 130/200). Pero si sostiene 50 solicitudes/segundo de forma continua, el búfer de 200 tokens se agota en cuestión de segundos, tras lo cual las solicitudes excedentes se limitan a la tasa de recarga de 30 TPS hasta que el volumen se normalice.

Importante: Dado que todas las credenciales bajo un mismo cliente comparten una única clave de API subyacente, crear múltiples credenciales (por ejemplo, para distintos servicios o casos de uso) no incrementa el rendimiento disponible.

Para evitar el throttling por ráfagas, recomendamos:

Distribuir las solicitudes uniformemente — extienda las solicitudes en el tiempo en lugar de enviarlas en grandes lotes.

Implementar un algoritmo de cubo de tokens o cubo con fuga en su propio sistema — estos patrones absorben naturalmente las ráfagas respetando los límites de tasa.

Monitorear proactivamente las respuestas 429 — trátelas como señal para reducir el ritmo de inmediato y reintentar con retroceso exponencial.

Evitar reintentos sincronizados — si múltiples procesos reintentan simultáneamente tras una falla, se puede amplificar la ráfaga. Agregue variación aleatoria (jitter) a los intervalos de reintento.

Pautas de rendimiento: consideraciones sobre límites de tasa y ráfaga

Límite de tasa#

Límite de ráfaga#

Límite de tasa

Límite de ráfaga