Cómo Solucionar el Error '429 Too Many Requests' en tu Aplicación Web
Tu aplicación web deja de funcionar repentinamente. Las llamadas a la API fallan. Los usuarios ven errores. ¿El culpable? HTTP 429 Too Many Requests—la forma que tiene el servidor de decirle a tu aplicación que reduzca la velocidad.
Esta guía explica qué causa los errores 429 en aplicaciones web modernas, cómo interpretar las señales que envían los servidores y estrategias prácticas de limitación de solicitudes en el frontend que previenen que estos errores ocurran.
Puntos Clave
- HTTP 429 indica que has excedido los límites de tasa—es una señal para reducir la velocidad, no un fallo del servidor.
- Utiliza los encabezados de límite de tasa (
X-RateLimit-*oRateLimit) y el encabezadoRetry-Afterpara guiar tu lógica de reintento. - Prevén los errores 429 mediante debouncing, agrupación de solicitudes y almacenamiento en caché agresivo.
- Cuando ocurran errores 429, implementa retroceso exponencial y encola los reintentos en lugar de saturar el servidor.
Qué Significa Realmente HTTP 429 Too Many Requests
El código de estado 429 indica que tu cliente ha excedido los límites de tasa establecidos por un servidor. A diferencia de los errores de la serie 500 (problemas del servidor) o 503 Service Unavailable (sobrecarga temporal), un 429 es explícito: estás haciendo demasiadas solicitudes y el servidor se está protegiendo.
La limitación de tasa de API puede originarse de múltiples fuentes:
- Tu propio backend aplicando límites por usuario o por sesión
- CDNs y WAFs bloqueando patrones de tráfico que parecen abusivos
- APIs de terceros protegiendo su infraestructura de llamadas excesivas
Cada fuente puede tener diferentes límites, diferentes ventanas de detección y diferentes comportamientos de recuperación. Una sola acción de usuario en tu aplicación podría desencadenar solicitudes a varios servicios, cualquiera de los cuales podría devolver un 429.
Comprendiendo los Encabezados de Límite de Tasa
Cuando los servidores implementan limitación de tasa, a menudo comunican los límites a través de encabezados de respuesta. Existen dos patrones:
Encabezados heredados usan el prefijo X-RateLimit-*:
X-RateLimit-Limit: Máximo de solicitudes permitidasX-RateLimit-Remaining: Solicitudes restantes en la ventana actualX-RateLimit-Reset: Cuándo se reinicia el límite (usualmente timestamp Unix)
Encabezados estandarizados siguen el formato más reciente RateLimit y RateLimit-Policy, que proporciona información similar con semántica mejor definida.
No todas las APIs usan estos encabezados. Algunas devuelven solo el estado 429 sin contexto adicional. Tu código debe manejar ambos escenarios.
El Encabezado Retry-After
El encabezado Retry-After indica a los clientes cuándo pueden reintentar de forma segura. Aparece en dos formatos:
Retry-After: 120 // segundos a esperar
Retry-After: Wed, 21 Oct 2025 07:28:00 GMT // timestamp específicoCuando esté presente, respétalo. Cuando esté ausente, implementa retroceso exponencial—espera progresivamente más tiempo entre reintentos (1 segundo, luego 2, luego 4, y así sucesivamente).
Algunos servidores omiten Retry-After por completo. Otros lo incluyen de forma inconsistente. Construye tu lógica de reintento para funcionar sin él mientras lo honras cuando esté disponible.
Discover how at OpenReplay.com.
Estrategias de Limitación de Solicitudes en el Frontend
La mayoría de los errores 429 en aplicaciones con frontend intensivo provienen de interacciones de UI que desencadenan llamadas excesivas a la API. Aquí te mostramos cómo prevenirlos:
Debounce en la Entrada del Usuario
Los cuadros de búsqueda, campos de autocompletado y filtros a menudo disparan solicitudes con cada pulsación de tecla. El debouncing espera hasta que el usuario deje de escribir antes de enviar la solicitud:
function debounce(func, delay) {
let timeoutId;
return function (...args) {
clearTimeout(timeoutId);
timeoutId = setTimeout(() => func.apply(this, args), delay);
};
}
// Esperar 300ms después de la última pulsación antes de buscar
const debouncedSearch = debounce(searchAPI, 300);Agrupa Solicitudes Relacionadas
En lugar de obtener datos para cada elemento individualmente, combina solicitudes donde las APIs lo soporten. Una solicitud para 50 elementos es mejor que 50 solicitudes individuales.
Almacena en Caché Agresivamente
Guarda respuestas que no cambian con frecuencia. Antes de hacer una solicitud, verifica si ya tienes datos válidos en caché. Esto aplica tanto a cachés del navegador como al almacenamiento en caché a nivel de aplicación.
Respeta las Señales de Límite de Tasa
Cuando recibas encabezados de límite de tasa, úsalos de forma proactiva. Si X-RateLimit-Remaining muestra que estás casi agotado, reduce la velocidad antes de llegar al límite.
Manejando los Errores 429 con Elegancia
Cuando ocurre un 429 a pesar de los esfuerzos de prevención:
- Analiza la respuesta buscando
Retry-Aftero encabezados de límite de tasa - Encola la solicitud fallida para reintento después del retraso especificado
- Informa a los usuarios apropiadamente—muestra un estado de carga, no un error
- Registra la ocurrencia para identificar patrones en tu monitoreo
Evita reintentos inmediatos. Saturar un servidor que acaba de decirte que reduzcas la velocidad empeora las cosas y puede desencadenar bloqueos más largos.
Ten en cuenta que algunos CDNs y WAFs aplican ventanas de enfriamiento fijas, lo que significa que los reintentos pueden ser bloqueados durante minutos independientemente de la lógica de retroceso del lado del cliente.
Distinguiendo 429 de Otros Errores
Un 429 requiere esperar. Un 503 podría resolverse rápidamente o indicar una interrupción mayor. Un 500 sugiere un bug. Tu manejo de errores debe diferenciar:
- 429: Retrocede, espera, reintenta con el retraso especificado
- 503: Reintenta con retroceso, pero monitorea interrupciones prolongadas
- 500: Registra el error, posiblemente reintenta una vez, luego falla elegantemente
Conclusión
HTTP 429 Too Many Requests es una señal de limitación de tasa, no un fallo. Prevénlo mediante limitación de solicitudes en el frontend—debouncing, agrupación y almacenamiento en caché. Cuando ocurra, respeta el encabezado Retry-After e implementa retroceso exponencial.
La mejor solución para los errores 429 es nunca desencadenarlos. Diseña tu aplicación para hacer solo las solicitudes necesarias, y rara vez verás este error en producción.
Preguntas Frecuentes
El debouncing espera hasta que la actividad se detenga antes de ejecutar una función, ideal para entradas de búsqueda donde quieres el valor final. El throttling limita la ejecución a una vez por intervalo de tiempo, mejor para eventos de scroll o acciones continuas. Ambos reducen el volumen de solicitudes, pero el debouncing típicamente funciona mejor para entrada de usuario que desencadena llamadas a la API.
Comienza con un retraso base como 1 segundo, luego duplícalo con cada intento de reintento. Agrega jitter aleatorio para prevenir reintentos sincronizados de múltiples clientes. Limita el retraso máximo para evitar esperas excesivas. Una secuencia típica podría ser 1s, 2s, 4s, 8s, luego detente después de 4-5 intentos.
Sí. Las APIs de terceros pueden tener límites estrictos por clave independientemente de tu tráfico general. Las direcciones IP compartidas en plataformas en la nube pueden desencadenar límites de tasa de CDN. Los patrones de ráfaga de cargas de página o montaje de componentes también pueden exceder los límites incluso con pocos usuarios totales.
Generalmente no. Dado que los errores 429 son temporales y recuperables, muestra un estado de carga mientras reintentas en segundo plano. Solo muestra un error si se agotan los reintentos. Los usuarios no necesitan saber sobre la limitación de tasa—solo quieren que su acción se complete.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
