Límites de velocidad y gestión de errores resiliente

Ganancias:

• Puede interpretar los límites de velocidad (RPM/ITPM/OTPM) y errores 429
• Implementa retroceso exponencial y reintento con reintento posterior
• Clasifica y maneja correctamente códigos de error HTTP comunes (400/401/429/500/529)

En un entorno de producción, ninguna API responde perfectamente todo el tiempo. A veces envías solicitudes demasiado rápido y alcanzas el límite; a veces el servidor está temporalmente ocupado; A veces tu solicitud es incorrecta desde el principio. Lo que distingue una integración sólida de un intento amateur es que maneja estas situaciones de manera predictiva y automática. En esta unidad aprenderá sobre los límites de velocidad (RPM/ITPM/OTPM), el error 429, el reintento con retroceso exponencial y la clasificación adecuada de los códigos de error HTTP comunes. El objetivo: crear un flujo que sea tan sólido que el usuario nunca lo note.

¿Qué son los límites de velocidad?

El proveedor limita la cantidad de trabajo que puede realizar un conmutador en un período de tiempo determinado. Esta protección; Protege tanto a la infraestructura como a usted de explosiones repentinas de costos. Hay tres tipos comunes de límites:

• RPM (Solicitudes por minuto): Número de solicitudes por minuto.
• ITPM (Tokens de entrada por minuto): Token de entrada que se puede procesar por minuto.
• OTPM (Tokens de salida por minuto): Token de salida que se puede producir por minuto.

Si excede cualquiera de estos límites, el proveedor rechaza la solicitud y devuelve un código de error 429. Los límites generalmente varían según el nivel de su cuenta y pueden aumentar con el tiempo.

Consejo: Puedes ver cuándo te acercas al límite en los encabezados de respuesta. La mayoría de los proveedores informan su cuota restante con encabezados como x-ratelimit-remaining-*. Monitorear estos valores y acelerar el tráfico en frente es la forma más madura de prevenir el problema sin recibir un 429.

429 y retroceso exponencial

429 (límite de velocidad) es un error temporal y reintentable. La respuesta correcta es esperar un rato la solicitud y volver a intentarlo. Pero una espera constante no es suficiente; Si todos vuelven a intentarlo al mismo tiempo, se volverá a alcanzar el límite. La solución es el retroceso exponencial: aumentar exponencialmente el tiempo de espera con cada intento fallido.

# Prueba lógica de retroceso exponencial 1 → 429 → esperar 1 segundo prueba 2 → 429 → esperar 2 segundos prueba 3 → 429 → esperar 4 segundos prueba 4 → 429 → esperar 8 segundos (+ pequeña "nerviosidad" aleatoria)... rendirse e informar después de como máximo N pruebas

Agregar un poco de aleatoriedad (jitter) a esto evita que las solicitudes colisionen al intentar reintentar al mismo tiempo. Además, la respuesta 429 a menudo lleva un encabezado "reintentar después": "inténtalo de nuevo dentro de estos segundos". Respetar este título es más exacto que esperar ciegamente.

Precaución: Cuando recibe un 429, "forzarlo enviando más solicitudes" empeorará la situación; El límite continúa llenándose y no se procesa ninguna solicitud. La respuesta correcta es retroceder, no acelerar. Buenas noticias: la mayoría de los SDK oficiales reintentan automáticamente los errores 429 y del servidor con una pausa; utilice este comportamiento del SDK antes de instalarlo manualmente.

Clasificación de códigos de error HTTP

No todos los errores son iguales. Distinción crítica: ¿se puede volver a intentar o es una cuestión de solicitud/identidad?

Código

Significado

¿Se puede volver a intentar?

respuesta correcta

400

Solicitud no válida (error de formato/parámetro)

no

Corregir la solicitud; no vuelvas a enviar lo mismo

401

Error de autenticación (clave no válida/faltante)

no

Arreglar clave/título

403

Sin autorización (sin acceso al modelo/función)

no

Verificar permisos/alcance

404

No encontrado (ID de modelo/punto final incorrecto)

no

ID/dirección correcta del modelo

429

Límite de velocidad excedido

si

Retirada + reintento después

500

error del servidor

si

Inténtalo de nuevo con retirada.

529

Servidor sobrecargado

si

Inténtalo de nuevo con retirada.

Regla de oro: 429, 500 y 529 son temporales; Se vuelve a intentar con retiro. 400, 401, 403, 404 son cuestiones de solicitud/identidad; Intentarlo de nuevo no solucionará el problema y será un desperdicio de esfuerzo. Su código debe distinguir entre estos dos grupos.

Paso a paso: Llamada duradera

1. Envíe la solicitud. Si tiene éxito, continúe.
2. Clasifica el código de error. ¿Se puede volver a intentar?
3. Si se puede intentar: siga el reintento posterior, aplique retroceso exponencial + fluctuación, intente un número limitado de veces (por ejemplo, 5 como máximo).
4. Si no se intenta: arreglar (formato/clave) y detener; No repita la misma solicitud errónea en el bucle.
5. Considere darse por vencido. Si aún no tiene éxito después de n intentos, muestre un mensaje cortés al usuario y registre el evento (unidad de seguimiento 11).

# Llamada robusta pseudo-codeene = 0repeat: respuesta = request_at() if respuesta.éxito: devuelve respuesta si respuesta.código en [429, 500, 529] e intenta < 5: espera = reintento_después? (2^intento seg + jitter) dormir(esperar); prueba += 1; git nuevamente si respuesta.código en [400, 401, 403, 404]: save_error(respuesta); devolver "la solicitud debe corregirse" devolver "error permanente, inténtelo más tarde"

# Comentarios amables para el usuario (cuando se agotan los reintentos) "Estoy ocupado en este momento, no pude procesar su solicitud. Vuelva a intentarlo pronto o guardé su solicitud. Me comunicaré con usted cuando esté lista".

Aviso débil / Aviso fuerte (aquí: diseño de mensaje de error)

# DÉBIL (muestra el error sin formato al usuario) "Error 429: rate_limit_error"

# STRONG (fácil de usar, tranquilizador, que sugiere acciones) "Hubo una congestión temporal en el sistema. Hemos recibido su solicitud de forma segura y se está intentando nuevamente automáticamente. Si no aparece un resultado en unos segundos, puede actualizar la página".

Revelar el error técnico en bruto al usuario final socava la confianza y puede ser una vulnerabilidad de seguridad. Clasifique los errores internamente y brinde al usuario un mensaje tranquilo y orientado a la acción; simplemente escriba el detalle técnico para que conste.

Tres mini estuches

Caso 1: Barco que se estrelló en una explosión de tráfico. Un robot de servicio al cliente recibió 429 aumentos de tráfico el día de la campaña; No hubo reintentos en el código, cada error se reflejaba directamente al usuario como un "error". Agregaron retroceso exponencial + reintento posterior; Con el mismo tráfico, las solicitudes pasaron con un retraso de varios segundos, el usuario no vio ningún error.

Caso 2: Probar 400 en el bucle. Una integración obtenía un error 404 debido a un ID de modelo no válido, pero trataba todos los errores como "transitorios" y volvía a intentarlo en un bucle infinito; El tronco se hinchó y se creó una carga innecesaria. Agregaron una clasificación de error: 404 se considera permanente, se detiene el bucle y se corrige la identificación del modelo. Lección: no vuelvas a intentar cada error.

Caso 3: Gestionar el límite desde el frente. Se ejecutaba constantemente un trabajo de enriquecimiento de datos al límite de 429. Siguieron el encabezado x-ratelimit-remaining y estrangularon el tráfico según la cuota. Así que mantuvieron un ritmo constante justo por debajo del límite, sin tomar ningún 429; El trabajo se realizó de forma más predecible y rápida.

Errores comunes

• Aumento de velocidad en 429: empeora la situación; Cambie a retirada.
• Reintentar cada error: 400/401/404 es permanente; Intentarlo de nuevo es un desperdicio.
• Usando espera fija: Crea una colisión; Utilice exponencial + fluctuación.
• Ignorar el 'reintento después': lo más preciso es cumplir con el tiempo especificado por el proveedor.
• Revelar el error en bruto al usuario: sacude la confianza, crea vulnerabilidades; Clasificar por dentro.
• Reintentos ilimitados: establezca un límite superior (por ejemplo, 5 reintentos); luego ríndete con gracia.

Más profundo: colas, concurrencia y disyuntores

La resistencia a un solo deseo es el primer paso; La verdadera madurez es gestionar una gran cantidad de solicitudes sin llegar a los límites. Aquí entran en juego tres conceptos.

Cola: coloca las solicitudes en una cola para enviarlas a un ritmo controlado en lugar de hacerlo de inmediato. Las colas suavizan las ráfagas repentinas de tráfico: incluso si llegan 1000 solicitudes a la vez, la cola las liberará a un ritmo inferior al límite. De esta manera evitas el 429 y no tienes que preocuparte por solucionarlo.

Límite de concurrencia: limita cuántas solicitudes están "en el aire" al mismo tiempo. Las solicitudes paralelas ilimitadas llenan rápidamente los límites de RPM y TPM. Un límite de concurrencia razonable (por ejemplo, no más de 10 solicitudes simultáneas) mantiene los límites y hace que el sistema sea predecible.

Disyuntor: si el proveedor sigue devolviendo 500/529, en lugar de intentar obstinadamente cada solicitud, usted "rompe el circuito" por un tiempo y rápidamente falla la solicitud sin siquiera enviarla. Después de una espera, vuelves a encender el circuito y lo intentas. Este patrón evita que su sistema falle en caso de una falla temporal del proveedor.

Juntos, estos tres establecen resiliencia a nivel de sistema más allá de la lógica de reintento de una sola llamada. A pequeña escala, el reintento automático del SDK es suficiente; A medida que crece la escala, las colas, la simultaneidad y los disyuntores se vuelven indispensables. Todos tienen el mismo objetivo común: reflejar un problema temporal al usuario no como un fallo, sino como un retraso invisible de unos segundos.

En resumen

429 regresa cuando se exceden los límites de velocidad (RPM/ITPM/OTPM); Este es un error temporal y se volverá a intentar utilizando el reintento posterior y el retroceso exponencial + fluctuación. 500 y 529 también son provisionales; 400/401/403/404 es un problema de solicitud/identidad y no se puede resolver intentándolo nuevamente. Un flujo sólido separa los errores en estos dos grupos, lo intenta un número limitado de veces, monitorea el límite desde el frente y muestra mensajes tranquilos al usuario.

Tarea de aplicación

Considere su integración. (1) Enumere los códigos de error que puede encontrar y sepárelos en "reintentables/permanentes". (2) Escriba su plan de retroceso exponencial (retención inicial, coeficiente, límite, fluctuación). (3) Especifique cómo utilizar el encabezado de reintento posterior. (4) Escriba el mensaje cortés que se mostrará al usuario cuando se agoten los reintentos.

lista de verificación

• [] Puedo explicar los límites de RPM/ITPM/OTPM y 429.
• [] Puedo aplicar la lógica de retirada exponencial + jitter + reintento posterior.
• [] Puedo clasificar los códigos de error como reintentables/permanentes.
• [] Sé que no debemos intentar cometer todos los errores.
• [] En lugar de un error sin formato, puedo mostrarle al usuario un mensaje tranquilo y orientado a la acción.