Planteamiento y contexto
Una API devuelve 429 Too Many Requests tras un pico de tráfico. Explica el límite de responsabilidad de este código de estado, cómo interpretar Retry-After, qué solicitudes se pueden reintentar y cómo evitar que el cliente convierta una sobrecarga en una falla en cascada.
Qué evalúa el entrevistador
- Comprender el 429 como una señal de límite de tasa (rate limit) en lugar de una falla permanente del servidor.
- Manejar correctamente ambos formatos de Retry-After y el escenario donde falta el encabezado.
- Combinar idempotencia, límites de tiempo (deadlines) y efectos secundarios de negocio al decidir reintentar.
- Proteger el servicio mediante backoff exponencial, jitter, presupuestos de reintentos (retry budgets) y control de tasa.
Preguntas para aclarar antes de responder
- ¿El límite es por usuario, token, tenant, IP o recurso compartido?
- ¿La respuesta contiene Retry-After y el cliente puede confiar en su reloj?
- ¿El método y la operación de negocio son idempotentes, o existe una clave de idempotencia?
- ¿Existen un deadline global, un límite máximo de reintentos y un presupuesto de reintentos?
- ¿El servicio expone cuota, capacidad restante o un ID de solicitud?
Estructura de respuesta en 30 segundos
Trato el 429 como retroalimentación de límite de tasa y leo Retry-After, que puede ser en segundos o una fecha HTTP. Respeto la indicación del servidor dentro de un límite seguro de backoff del cliente y añado jitter. Solo reintento automáticamente operaciones idempotentes o protegidas por una clave de idempotencia, con límites de deadline, intentos y presupuesto. Sin Retry-After, utilizo backoff exponencial con jitter; ante 429 reiterados, me detengo y devuelvo el control al invocador.
Análisis detallado paso a paso
Paso 1: Confirmar la semántica del 429
RFC 6585 define el 429 para un exceso de solicitudes en un período determinado y permite el uso de Retry-After. Le indica al cliente que reduzca la tasa; no debe tratarse como un 500 ni reintentarse de inmediato.
Paso 2: Analizar Retry-After
Retry-After puede ser un número entero no negativo de segundos o una fecha HTTP. Para una fecha, utiliza el encabezado Date de la respuesta o un reloj de confianza para estimar el retraso, y acota los valores negativos, gigantescos o mal formados.
Retry-After: 8
Retry-After: Wed, 02 Aug 2026 02:00:00 GMTPaso 3: Decidir si la repetición es segura
Los métodos seguros como GET y HEAD suelen ser reintentables. Las escrituras requieren semántica idempotente, una clave de idempotencia o deduplicación del lado del servidor. Incluso un mismo método puede tener efectos secundarios como cobrar, enviar correos o crear una tarea.
Paso 4: Calcular el retraso y el backoff
Respeta Retry-After primero, luego aplica un tope de backoff exponencial en el cliente y jitter aleatorio. El jitter evita que muchos clientes se reactiven en el mismo instante. La espera debe ajustarse al deadline de la solicitud en lugar de extenderlo indefinidamente.
Paso 5: Limitar la amplificación de reintentos
Establece intentos por solicitud, un presupuesto global de reintentos y un límite de concurrencia. Reduce la tasa para un recurso que continúa devolviendo 429; utiliza una cola local o un circuit breaker cuando sea necesario para que los reintentos no consuman la capacidad del tráfico normal.
Paso 6: Separar las responsabilidades del cliente y del servidor
El servidor proporciona una señal de límite explícita y campos observables. El cliente respeta la señal, retrocede (back off) y se detiene. Tras la recuperación, incrementa el tráfico gradualmente en lugar de liberar todas las solicitudes en espera a la vez.
Paso 7: Registrar resultados y mejorar
Monitorea la tasa de 429, la distribución de Retry-After, la tasa de éxito final, el conteo de reintentos y los abandonos por deadline. Utiliza estos datos para ajustar cuotas, presupuestos de clientes y alertas, en lugar de tratar el 429 como una falla aislada de una sola solicitud.
Respuesta de muestra de alta calidad
Primero confirmaría la dimensión del límite y los encabezados de respuesta. Con Retry-After: 8, el cliente espera al menos ocho segundos; con una fecha HTTP, calcula el retraso usando un reloj confiable y un límite máximo. Una consulta de orden con clave de idempotencia puede reintentarse automáticamente, mientras que la creación de un cobro sin deduplicación debe ser confirmada por la capa de negocio. Utilizo backoff exponencial con jitter aleatorio, un tope de tres intentos por solicitud, un presupuesto global de reintentos y un deadline general. Los 429 persistentes reducen la concurrencia y pausan la cola para que los reintentos no amplifiquen la sobrecarga. Las métricas abarcan la tasa de 429, el tiempo de espera y la tasa de éxito final para el ajuste de cuotas y alertas.
Errores comunes
- Tratar el 429 como un 500 y reintentar de inmediato en un bucle cerrado.
- Soportar únicamente el formato entero de Retry-After e ignorar el formato de fecha HTTP.
- No distinguir entre lecturas idempotentes y escrituras con efectos secundarios.
- Omitir deadlines, presupuestos o límites de concurrencia, haciendo que los reintentos crezcan sin control.
- Asignar a todos los clientes el mismo retraso fijo, creando un pico sincronizado de reintentos.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuánto tiempo se debe esperar si no hay Retry-After?
Utiliza un backoff exponencial con jitter junto con límites de retraso máximo, número de intentos y deadline total. Ajústalo según la tasa de 429 y la cuota, en lugar de elegir una constante fija permanente.
Pregunta de seguimiento 2: ¿Qué pasa si la fecha HTTP está en el pasado?
Trata el retraso del servidor como cero, pero sigue aplicando backoff local y jitter, y registra un problema de reloj o de generación del servidor. No lances reintentos de alta concurrencia solo porque la fecha sea inválida.
Pregunta de seguimiento 3: ¿Se puede reintentar un POST?
Solo cuando la API define idempotencia, proporciona una clave de idempotencia o la capa de negocio puede deduplicar. De lo contrario, regresa el control al invocador para una decisión explícita de reenvío.
Pregunta de seguimiento 4: ¿Qué ocurre si muchas instancias comparten una misma cuota?
Coordina los presupuestos de reintentos y el control de tasa entre procesos o a nivel de tenant, utilizando señales compartidas para reducir la concurrencia. El backoff por instancia no puede evitar el exceso de consumo agregado.
Pregunta de seguimiento 5: ¿Cómo evitar otro pico de sobrecarga durante la recuperación?
Incrementa la cola gradualmente, mantén el jitter y un límite de concurrencia, y aumenta la tasa solo después de observar los 429 y la latencia. No liberes todas las solicitudes en espera a la vez.
Pregunta de seguimiento 6: ¿Qué métricas demuestran que la estrategia funciona?
Compara la tasa de 429, la amplificación de reintentos, la tasa de éxito, la latencia P95, los abandonos finales y el tiempo de recuperación, segmentados por tenant o recurso.