Si alguna vez has visto un HTTP 429 – Too Many Requests en producción, sabes que no es un error cualquiera.

No rompe nada de golpe.

No es un 500.

Pero es una advertencia clara:

“Vas demasiado rápido. Para.”

Y si sigues ignorándolo, lo siguiente ya no es un 429.

Es un bloqueo temporal, o peor, un bloqueo de IP.

En este artículo vamos a ver cómo evitar el error 429, cómo no martillear una API, y qué patrones usan los sistemas “educados” para convivir con APIs de terceros sin acabar en la lista negra.

Qué es el error 429 y por qué aparece

El error 429 Too Many Requests significa exactamente lo que dice:

has superado el número de peticiones que la API considera razonable en un periodo de tiempo.

Pero ojo:

no siempre es solo un número fijo tipo “100 requests por minuto”.

Muchas APIs miran cosas como:

  • picos bruscos (todo a la vez)
  • reintentos sincronizados
  • demasiadas conexiones concurrentes
  • patrones “raros” que parecen bots

Por eso a veces piensas:

“No he superado el límite… ¿por qué me devuelve 429?”

Porque el problema no es solo cuánto llamas, sino cómo llamas.

El error clásico: tratar una API como si fuera infinita

La mayoría de bloqueos no vienen de un uso alto y constante.

Vienen de picos artificiales.

Ejemplo típico:

  • tu sistema arranca
  • o hay un evento a las 09:00
  • o algo falla y reintentas todo a la vez
  • boom: cientos o miles de requests en segundos

Desde tu punto de vista: “todo normal”.

Desde el de la API: pareces un ataque.

Aquí es donde entran los patrones importantes.

Jitter: deja de hacer todo a la vez

Jitter es una palabra fancy para algo muy simple:

meter un poco de aleatoriedad en el tiempo.

Sin jitter:

  • 500 peticiones fallan
  • todas esperan 30 segundos
  • todas reintentan exactamente a los 30 segundos
  • vuelven a fallar todas a la vez

Con jitter:

  • una espera 31s
  • otra 47s
  • otra 62s

Resultado:

el mismo trabajo, pero repartido en el tiempo.

Las APIs odian las estampidas sincronizadas.

El jitter las desactiva casi por arte de magia.

Backoff: cuanto peor va, menos insistas

Backoff significa que cada fallo hace que esperes más antes de reintentar.

No es castigo.

Es educación.

Un patrón típico:

  • primer fallo → reintento rápido
  • segundo fallo → esperas más
  • tercer fallo → esperas bastante más
  • cuarto fallo → paras o marcas como fallido

Si una API va mal ahora,

es muy probable que siga yendo mal dentro de 5 segundos.

Insistir rápido no ayuda a nadie.

Retry-After: cuando la API te habla, hazle caso

Algunas APIs, cuando te devuelven un 429, incluyen un header:

Retry-After: 120

Traducción:

“No me llames antes de 120 segundos.”

Esto no es una sugerencia.

Es un contrato implícito.

Ignorar Retry-After es una de las formas más rápidas de que una API te bloquee de verdad.

Si está, se respeta.

Siempre.

Circuit breaker: saber parar a tiempo

Uno de los mayores errores en sistemas distribuidos es no saber cuándo dejar de llamar.

Para eso existe el circuit breaker.

La idea es simple:

  • detectas muchos fallos seguidos
  • paras las llamadas durante un tiempo
  • después pruebas con cuidado
  • si sigue mal, paras otra vez

Estados típicos:

  • Closed: todo normal
  • Open: no se llama a la API
  • Half-open: pruebas con pocas peticiones

Esto protege:

  • a la API
  • a tu sistema
  • a tu IP

Un sistema que sabe parar parece maduro.

Uno que insiste parece un bot.

Ramp-up: no empieces gritando

Otro patrón sospechoso: pasar de 0 a 500 requests en un segundo.

Aunque tengas permiso.

El ramp-up consiste en subir carga poco a poco:

  • empiezas con pocas peticiones concurrentes
  • vas aumentando gradualmente
  • llegas al máximo de forma progresiva

Especialmente importante:

  • tras reinicios
  • tras despliegues
  • tras una caída
  • tras un circuit breaker

Desde fuera, tu tráfico parece normal.

Eso importa más de lo que crees.

Limitar peticiones API también es cosa tuya

No todo depende de la API externa.

Tu sistema debería:

  • controlar su propia concurrencia
  • limitar requests por segundo
  • evitar bucles de reintentos
  • cachear respuestas cuando tenga sentido

Si sabes que un dato no cambia cada segundo, no lo pidas cada segundo.

Esto reduce:

  • 429
  • latencia
  • coste
  • y disgustos

Monitoriza, o irás a ciegas

Si no mides, no sabes por qué te bloquean.

Mínimo deberías ver:

  • cuántos 429 recibes
  • cuándo ocurren
  • cuántos reintentos haces
  • cuánto tiempo pasan las peticiones en cola

Muchos problemas de rate limit se arreglan solo mirando una gráfica.

El patrón invisible: parecer educado

Nada de esto va de “exprimir límites”.

Va de comportarse como un buen ciudadano de red.

Un sistema educado:

  • no insiste cuando le dicen que no
  • no reintenta todo a la vez
  • no genera picos artificiales
  • sabe parar
  • vuelve poco a poco

Las APIs no suelen castigar el volumen estable.

Castigan el comportamiento errático.

Conclusión

El error 429 Too Many Requests no es tu enemigo.

Es una señal.

Te está diciendo:

“Baja el ritmo y piensa un poco mejor cómo llamas.”

Si aplicas:

  • jitter
  • backoff
  • retry-after
  • circuit breaker
  • ramp-up
  • y control de concurrencia

no solo evitas que una API te bloquee,

sino que construyes sistemas más estables y profesionales.

Si este artículo te ha sido útil, compártelo con alguien que esté peleándose ahora mismo con un 429 en producción.

Seguro que se lo ahorra.