Mida los límites de la API del broker antes de que lleguen los picos

Una respuesta 429 no es una estrategia para limitar la tasa de solicitudes. Es una señal de que un cliente ya ha llegado a un límite, y la respuesta por sí sola rara vez indica al equipo de operaciones si la causa fue un pico, una cuenta con demasiada actividad, un bucle de reintentos o un problema de capacidad que afecta a todo el proveedor. La pregunta útil es cuánta demanda se acerca a ese límite, con qué rapidez puede reducirse y qué flujos de trading deben seguir funcionando.

Las API de los brokers suelen aplicar límites en varias capas: por credencial, cuenta, dirección IP, endpoint o conexión simultánea. Un límite puede usar una ventana móvil, un bucket de tokens o un intervalo fijo.

Como punto de partida para la planificación, las API de brokers y proveedores podrían tener un rango de 5 a 50 solicitudes por segundo por credencial, con límites inferiores en determinados endpoints, pero la política real depende del proveedor y puede cambiar. Trate las cuotas publicadas como restricciones que hay que probar, no como una garantía de capacidad.

Sepa qué límite está midiendo

Primero, asocie cada operación de la API con su probable cuota y su propósito empresarial. Una consulta instantánea de cotizaciones, una consulta de cuenta, el envío de una orden y la comprobación del estado de una orden pueden tener costes distintos. Algunas API cuentan las solicitudes, mientras que otras aplican límites separados para la entrada de órdenes, las cancelaciones o las sesiones simultáneas. Un cliente que agrupa todo en un único contador global de solicitudes no puede explicar qué carga consumió su presupuesto.

Registre el código de respuesta, el endpoint, la credencial o el identificador de cuenta, el peso de la solicitud si se proporciona y cualquier cabecera con información sobre límites. Algunas cabeceras habituales indican la cuota restante, el momento en que se restablece o el tiempo de espera antes de reintentar. Captúrelas tanto en respuestas satisfactorias como en errores. Si el proveedor no proporciona cabeceras, deduzca la presión a partir de la frecuencia de respuestas 429 y de pruebas controladas en un entorno que no sea de producción. No dé por sentado que una respuesta 429 de un endpoint significa que todos los endpoints están bloqueados.

Separe los límites estrictos del estado del servicio. Una respuesta 429 suele indicar que se ha alcanzado una cuota, mientras que una respuesta 5xx apunta a un fallo del servidor, aunque los proveedores no siempre respetan perfectamente esa distinción. Lea el cuerpo de la respuesta y las directrices del proveedor. Un tiempo de espera es más ambiguo: puede que una orden se haya aceptado aunque el cliente nunca recibiera la confirmación. Repetir a ciegas el envío de una orden puede crear un duplicado, salvo que la API admita claves de idempotencia o que el cliente reconcilie primero el estado de la orden.

Para obtener una cobertura más amplia de la infraestructura, la información de Trading Technology sobre infraestructura complementa los detalles operativos que los equipos deben registrar internamente: los pesos de las solicitudes, las asignaciones para ráfagas y el comportamiento de recuperación.

Mida la presión, no solo las respuestas 429

Cuente por separado los intentos y las respuestas satisfactorias. Para cada endpoint y grupo de cuentas, registre las solicitudes por segundo, las respuestas 429 como proporción de los intentos, las tasas de tiempos de espera y de respuestas 5xx, el volumen de reintentos y la fracción de la cuota disponible que se ha consumido.

Añada la profundidad de la cola y la antigüedad del elemento más antiguo. Una tasa baja de respuestas 429 aún puede ocultar un cliente casi saturado si las solicitudes esperan en una cola antes de llegar al broker.

Use un intervalo corto para detectar ráfagas y otro más largo para analizar tendencias. Los bloques de uno o cinco segundos revelan picos que desaparecen en un promedio calculado por minutos.

Mantenga la latencia p50, p95 y p99 tanto de la cola del cliente como del recorrido completo de ida y vuelta de la API. Etiquete cada medición con la operación y el resultado. Sin esas dimensiones, un aumento aparente de la latencia podría deberse a consultas lentas de cuentas y no a confirmaciones de órdenes.

Entre las señales operativas útiles se incluyen:

• Margen de cuota: solicitudes disponibles divididas por el límite durante la ventana pertinente, cuando el proveedor expone ambos valores.
• Amplificación de reintentos: todos los intentos divididos por las solicitudes lógicas originales. Un aumento de 1.0 a 1.5 significa que cada solicitud de negocio genera, en promedio, media llamada adicional a la API.
• Antigüedad de la cola: el tiempo transcurrido entre el momento en que una tarea pasa a estar disponible y el momento en que el cliente la envía. Registre la tarea más antigua, además de la mediana.
• Estado del flujo de órdenes: latencia de envío y confirmación, envíos rechazados y tiempos de espera sin resolver. No mezcle estos datos con el tráfico de solo lectura.

Configure alertas basadas en varias señales, no en un único umbral. Por ejemplo, un uso sostenido de la cuota por encima del 80 por ciento junto con un aumento de la antigüedad de la cola justifica limitar el tráfico de forma proactiva, incluso antes de que aparezcan respuestas 429. La cifra del 80 por ciento es un umbral operativo inicial, no una regla universal. Póngala a prueba con el tamaño de las ráfagas, las ventanas de restablecimiento del proveedor y el tiempo de recuperación que sus flujos de trabajo pueden tolerar.

El backoff es un mecanismo de control del tráfico

Cuando se rechaza una solicitud, reintentarla de inmediato aumenta la carga justo cuando la presión es máxima. Use backoff exponencial con jitter para las consultas que admiten reintentos y otras operaciones seguras. Un esquema habitual podría empezar con 200 a 500 milisegundos, multiplicar el retraso aproximadamente por dos tras cada fallo y limitarlo a entre 5 y 30 segundos. Aleatorice el retraso para evitar que un grupo de clientes se active y reintente al mismo tiempo.

Respete un valor válido de Retry-After en lugar de un retraso calculado localmente. Establezca un número máximo de intentos y un presupuesto total de tiempo para los reintentos.

Cuando se agote cualquiera de los dos, envíe la tarea a una cola con demora o márquela para revisión operativa, en vez de reintentarlo indefinidamente. En las operaciones no idempotentes, reintente solo cuando el mecanismo de idempotencia de la API y la lógica de conciliación del cliente garanticen que el resultado es seguro.

El backoff necesita una condición de restablecimiento. Si un cliente pone a cero su contador de fallos después de un solo éxito, puede volver rápidamente a la velocidad máxima y recrear la ráfaga. Puede ser más seguro recuperarse gradualmente, por ejemplo, aumentando la tasa de envío permitida por etapas a lo largo de decenas de segundos. Ajuste el intervalo al comportamiento de restablecimiento documentado por el proveedor y a la velocidad a la que crece la cola. Si la cola sigue acumulando antigüedad durante la recuperación, la progresión es demasiado rápida o la demanda entrante sigue superando la capacidad.

Distinga entre la limitación de tráfico del lado del cliente y el backoff del lado del servidor. Un bucket de tokens puede suavizar las ráfagas locales, mientras que un límite de concurrencia puede evitar que demasiadas solicitudes lentas estén en curso al mismo tiempo.

Ambos controles protegen al cliente y al proveedor, pero ninguno aumenta la cuota disponible. Mida si limitar la concurrencia reduce los tiempos de espera y compruebe que el atraso no se limite a pasar de la capa de red a una cola interna.

Limite el tráfico según la prioridad del negocio

Una única cola con planificación por orden de llegada permite que las consultas periódicas rutinarias desplacen a las acciones urgentes. Asigne presupuestos de solicitudes por carga de trabajo y cuenta.

El envío de órdenes, las cancelaciones y los controles de riesgo suelen necesitar una parte reservada de la capacidad; las actualizaciones de cuentas, las consultas históricas y los análisis no esenciales pueden usar la capacidad sobrante o aplazarse. El orden de prioridad exacto depende de los controles de la empresa y del contrato de la API del broker.

Defina explícitamente la política. Por ejemplo, reserve una parte del presupuesto del cliente para el flujo de órdenes, limite las consultas periódicas de baja prioridad y detenga las tareas opcionales cuando la tarea crítica más antigua supere su umbral de latencia.

Aplique límites por cuenta, además de límites globales. Una sola cuenta con mucha actividad no debería consumir toda la asignación compartida si otras cuentas dependen de la misma credencial.

Antes de pasar a producción, compruebe qué ocurre cuando coinciden los límites:

• ¿Se puede enviar una cancelación cuando las consultas de cotizaciones o de cuentas han agotado su presupuesto?
• ¿Un disyuntor pausa solo el endpoint que falla o también bloquea operaciones no relacionadas?
• ¿Las solicitudes en cola pueden caducar o quedar obsoletas antes de enviarse, especialmente las consultas sensibles al precio?
• ¿Los operadores pueden identificar claramente qué cuenta o servicio está consumiendo capacidad?

Estos controles necesitan un modo de fallo definido. Puede ser aceptable descartar actualizaciones obsoletas de datos de mercado; descartar silenciosamente una cancelación no lo es.

Conserve suficiente contexto para reproducir o conciliar el trabajo aplazado, y haga visibles las caducidades de la cola en las alertas y los registros. Los equipos que hacen seguimiento de la tecnología de los brokers y las operaciones de plataformas deben validar igualmente estos comportamientos con la topología de sus propias cuentas y la documentación del proveedor.

Asigne un coste al exceso de demanda

Los incidentes relacionados con límites de tasa consumen más que la cuota de la API. Los reintentos aumentan la carga, el trabajo en cola añade latencia y la conciliación genera esfuerzo operativo. Los rangos siguientes son estimaciones habituales de planificación para distintas implementaciones de API, no garantías del proveedor ni resultados auditados. Mida los valores locales antes de fijar objetivos de servicio.

Convierta esos costes en un presupuesto de capacidad. Supongamos que un cliente envía 20 solicitudes lógicas por segundo y que los reintentos elevan la proporción de intentos a 1.5. Ahora realiza 30 intentos por segundo, sin contar las consultas periódicas ni otros servicios que compartan la credencial. Si el límite configurado para el cliente es de 35 intentos por segundo, solo quedan cinco para todo el resto del trabajo. Es un punto operativo frágil, aunque el límite publicado por el proveedor sea mayor.

Mida también el coste de limitar el tráfico. Un tope restrictivo puede aumentar la antigüedad de la cola y retrasar trabajo útil, mientras que uno demasiado generoso puede provocar ciclos reiterados de rechazo y recuperación. Compare la antigüedad p95 de cada carga de trabajo con su plazo de negocio y, después, ajuste los presupuestos para que el trabajo crítico se mantenga dentro de su propio límite. Informe tanto del tráfico protegido como del trabajo aplazado, para que un flujo de órdenes aparentemente saludable no oculte un atraso creciente en otras áreas.

Valide los límites sin perjudicar el flujo de órdenes

No descubra los límites de producción enviando ráfagas a endpoints de órdenes en vivo. Reproduzca los patrones de solicitudes en un entorno de pruebas cuyas limitaciones sean representativas y, después, confirme el comportamiento en producción mediante observación prudente y coordinación con el proveedor. Las cuotas del entorno de pruebas pueden ser distintas, así que son útiles para probar la lógica del cliente, pero menos fiables para estimar la capacidad en producción.

Use esta lista numerada antes de modificar el limitador de tráfico de un cliente:

1. Inventario de límites: documente el endpoint, la credencial, la cuenta, el peso de la solicitud, el límite de concurrencia, la ventana de restablecimiento y las cabeceras de respuesta del proveedor.
2. Demanda de referencia: recopile las tasas de solicitudes de uno y cinco segundos, la latencia p95 y p99, la tasa de respuestas 429, la amplificación de reintentos y la antigüedad de la cola durante, como mínimo, un periodo de trading representativo.
3. Clasificación de operaciones: marque las solicitudes como críticas para las órdenes, críticas para el riesgo, sensibles a la actualidad de los datos o aplazables. Registre qué llamadas admiten reintentos seguros y cuáles requieren conciliación.
4. Definición de presupuestos: configure límites por endpoint y cuenta por debajo del límite conocido, reserve capacidad para las operaciones críticas y documente el motivo de cada margen.
5. Prueba de las vías de fallo: simule respuestas 429, respuestas retrasadas, tiempos de espera y errores 5xx. Verifique el jitter, los límites de reintentos, la idempotencia y la caducidad de la cola.
6. Revisión de la recuperación: compruebe que el tráfico se restablezca de forma gradual, que las colas se vacíen dentro de los objetivos de servicio y que las alertas identifiquen el endpoint y la cuenta que originan la presión.

Mantenga los paneles de control con el mismo nivel de detalle que la política de control. Si la limitación se aplica por cuenta, pero la supervisión solo muestra un promedio global, será difícil detectar una ráfaga específica de una cuenta. Revise los límites después de cambios en los endpoints, nuevos lanzamientos de cuentas, cambios en la frecuencia de las consultas periódicas o actualizaciones de la política del proveedor. Una pequeña revisión programada permite detectar cambios en las cuotas antes de que provoquen un incidente en producción.

Esta semana, instrumente y represente en un gráfico la amplificación de reintentos por endpoint junto con la antigüedad de la cola para una API de producción.

#limitación de velocidad de la API del broker #limitación de tasa de la API #espera exponencial #HTTP 429 #presupuestos de solicitudes #fiabilidad de la API de órdenes #lógica de reintentos #monitorización de API