Prompt y alcance
Esto evalúa el límite del protocolo del rate limiting, no simplemente un contador en Redis. La RFC 6585 define el código 429 para un exceso de solicitudes en un período y permite Retry-After; la RFC 9110 define segundos y una fecha HTTP. Convierta esa semántica en un comportamiento que los clientes puedan ejecutar de forma segura.
Qué evalúa el entrevistador
- Claves de límite, ventanas, cuotas y campos de respuesta que expliquen quién está limitado y cuándo es posible la recuperación.
- Cuerpo del 429 consistente, Retry-After, ID de solicitud y detalles seguros de la cuota.
- Análisis de segundos o fechas por parte del cliente, jitter, plazos límite (deadlines) y presupuestos de intentos.
- Límites de reintento para escrituras no idempotentes, tareas asíncronas y tiempos de espera de red.
- Métricas para impactos de límite, tiempo de recuperación, amplificación de reintentos y éxito eventual.
Estructura de respuesta recomendada
Defina las dimensiones de los límites y las clases de error. Muestre una respuesta 429 y la regla de Retry-After. El cliente utiliza el encabezado, el tipo de solicitud y el presupuesto local para esperar, abandonar o cambiar a trabajo asíncrono; cada reintento utiliza un backoff exponencial con límite y jitter. Cierre con las responsabilidades del gateway, la aplicación, el SDK y las operaciones de negocio, junto con pruebas de inyección de fallas.
Análisis profundo: de la respuesta al reintento
Haga que el límite sea explicable
Establezca las claves de los límites por tenant, credencial, IP, endpoint o un recurso global. Devuelva un tipo de error estable, el ID de la solicitud y un motivo seguro. Si se activan varios limitadores, use la espera conocida más larga sin revelar la cuota de otro tenant.
Genere Retry-After correctamente
Un retraso indica al menos cuántos segundos se debe esperar; una fecha HTTP indica el momento exacto de recuperación. Calcule las ventanas internas con un reloj monotónico, redondee hacia arriba y limite el valor máximo. Los clientes aún necesitan una espera mínima y jitter, ya que las fechas pueden verse afectadas por el desfase de reloj (clock skew) o proxies.
Analice y aplique backoff en el cliente
Respete Retry-After primero; si falta o no es válido, use un backoff exponencial con límite máximo. Otorgue a cada solicitud lógica un plazo total y un presupuesto de intentos. Coordine el trabajo concurrente mediante una cola compartida o un presupuesto de tokens para que muchas tareas no se reactiven al mismo tiempo.
Respete los límites de idempotencia
GET, HEAD y los PUT o DELETE explícitamente idempotentes suelen ser reintentables. POST requiere una clave de idempotencia y una semántica coincidente en el servidor. Si se perdió una respuesta tras la ejecución, consulte el estado o reutilice la misma clave en lugar de crear un segundo efecto secundario.
Observe la recuperación, no solo los errores
Registre la dimensión del límite, el conteo de 429, la distribución de Retry-After, la espera del cliente, la amplificación de reintentos, el éxito eventual y el abandono. Segmente por versión del SDK y tenant para distinguir un reintento inmediato de un crecimiento legítimo de tráfico.
Respuesta de ejemplo
“Limitaría la tasa por tenant, credencial y endpoint, devolviendo un tipo de error estable, ID de solicitud, motivo seguro y Retry-After. El servidor calcula un retraso de ventana monotónica, lo redondea hacia arriba y le aplica un límite máximo. Los SDK analizan Retry-After primero y, de lo contrario, usan backoff exponencial con jitter; cada solicitud lógica tiene un plazo y un límite de intentos. GET es reintentable; POST necesita una clave de idempotencia o una consulta de estado. Monitorearía los 429, la distribución de esperas, la amplificación de reintentos, el éxito eventual y el abandono, y luego ejecutaría una prueba multiservidor sincronizada para verificar una recuperación fluida.”
Modos de falla comunes y soluciones
- Reintentar cada falla → Clasificar por estado, semántica del método y tipo de error.
- Ignorar los formatos de Retry-After → Admitir segundos y fechas HTTP, y descartar valores no válidos de forma segura.
- Reintento inmediato por hilo → Compartir un presupuesto, cola y jitter.
- Asumir que POST es idempotente → Usar una clave de idempotencia, consulta de estado o un resultado explícito de no reintentar.
- Monitorear solo el conteo de 429 → Medir la espera, la amplificación, el éxito eventual y el abandono.
Rúbrica de evaluación y autoverificación
Las respuestas sólidas cubren claves de límites, semántica de 429, generación y análisis de Retry-After, backoff con jitter, plazos límites, idempotencia, coordinación de concurrencia, detalles seguros de cuotas, responsabilidades de los componentes y métricas de validación.
Pregúntese: ¿Sabe el cliente cuándo es posible la recuperación? ¿Qué pasa si los relojes difieren? ¿Qué pasa si falta el encabezado? ¿Pueden los reintentos duplicar efectos secundarios? ¿Cómo se distribuyen las tareas concurrentes? ¿Qué demuestra que la recuperación mejoró?
Preguntas de seguimiento y extensiones
¿Debería Retry-After usar segundos o una fecha?
Ambas son formas HTTP válidas. Los segundos convienen para ventanas cortas y evitan diferencias de reloj; una fecha puede expresar un punto de recuperación conocido. Mantenga la salida del servidor consistente mientras hace que el análisis del SDK sea compatible con ambos formatos y maneje valores expirados.
Si tanto el gateway como la aplicación aplican límites, ¿qué espera se devuelve?
La espera visible para el cliente debe cubrir todos los límites conocidos, normalmente la más larga, junto con un ID de solicitud. La telemetría interna registra cada capa para que un rechazo del gateway no se atribuya erróneamente a la aplicación.
¿Puede un cliente reintentar sin Retry-After?
Solo cuando la semántica del método y del error lo permitan, quede tiempo dentro del plazo límite y el presupuesto local de backoff sea suficiente. Use backoff con jitter y límite máximo; para escrituras no reintentables, devuelva un estado consultable o un fallo explícito.
¿Cómo se prueba una tormenta de reintentos?
Sincronice muchos clientes para desencadenar 429, luego inyecte encabezados no válidos, desfase de reloj, tiempos de espera de conexión y jitter de recuperación. Observe las curvas de llegada, la amplificación, el tiempo de recuperación y el éxito eventual.