¿El libro de órdenes se congela cuando sube la actividad del mercado? Cómo arreglar el feed de datos de mercado y quién puede hacerlo

Si el libro de órdenes de tus pantallas de trading se congela, da saltos o muestra precios imposibles cuando hay mucha actividad en el mercado, el fallo suele estar en uno de tres sitios. Las actualizaciones se pierden donde entra el feed del exchange, el libro se monta mal o llega demasiado despacio a cientos de pantallas. Mide tu hora de más actividad antes de contratar a nadie y después pon a prueba a cada empresa que consideres con una grabación de ese día.

¿Cómo se ve en pantalla un feed de datos de mercado roto?

Aparece en los momentos de más actividad, como un anuncio de un banco central o la apertura del mercado. El libro de la pantalla se detiene un segundo o dos y luego da un salto. Las órdenes canceladas siguen a la vista. A veces el precio más alto que ofrece un comprador queda por encima del precio más bajo que pide un vendedor, lo que se llama libro cruzado. En un solo exchange, fuera de las subastas de apertura y de cierre, esas órdenes se ejecutarían entre sí al instante. Así que un libro cruzado de un solo exchange en tu pantalla significa que tu copia de ese libro está mal.

Después, a soporte le llegan capturas de pantalla de dos traders que ven libros distintos para el mismo instrumento. O un trader discute el precio al que se ejecutó una orden, porque la pantalla mostraba otro.

¿Por qué se pierden actualizaciones o llegan desordenadas?

El feed del libro de órdenes de un exchange es un flujo de pequeños cambios: una orden añadida, una orden cancelada, una operación. Tu sistema parte de una copia completa del libro, llamada snapshot, y aplica los cambios en orden. Cada cambio lleva un número, así que se puede detectar el que falta. La especificación de Nasdaq para su feed TotalView-ITCH 5.0 dice que el feed «está formado por una serie de mensajes secuenciados», es decir, numerados en orden.

Cuando hay mucha actividad en el mercado, el flujo de cambios se dispara. Algunos se pierden por el camino o dentro de tus propios servidores, y otros llegan desordenados. Si el sistema no detecta el hueco, aplica lo que llega y muestra un libro que ya no coincide con el del exchange. Si detecta el hueco pero tarda segundos en recuperarse, la pantalla se queda congelada.

Los exchanges dan por hecho que sus clientes perderán actualizaciones. La documentación de CME Group para su feed MDP 3.0 dice que, tras un hueco, «debe suponerse que es posible que todos los libros mantenidos en el sistema del cliente ya no tengan el estado correcto y más reciente».

¿En qué parte del sistema se rompe el feed?

Son tres sitios, y cada uno necesita su propio arreglo. Los ingenieros llaman fan-out al tercero, porque un único flujo de actualizaciones se reparte en abanico a muchas pantallas. El artículo técnico enlazado arriba trata los tres en detalle.

El primer sitio es la entrada del feed, donde llega el feed del exchange. Algunos exchanges ofrecen formas de recuperar los datos perdidos. Uno de los protocolos de entrega de Nasdaq, MoldUDP64, permite a los receptores «detectar y volver a solicitar los paquetes perdidos». CME envía su flujo por duplicado, por líneas llamadas A y B, y mantiene un feed aparte de snapshots para poner los libros al día. Nada de esto sirve si tu sistema no detecta el hueco.

Después se monta el libro, y aquí el peligro es un cambio aplicado dos veces, fuera de orden o sobre el snapshot equivocado. Binance, un exchange de criptomonedas, detalla en su guía los pasos exactos para empalmar un snapshot con el flujo en vivo. Un libro montado sin ellos sigue mostrando precios y parece correcto, pero los precios están mal.

Por último viene el fan-out, donde el libro sale hacia cientos de sesiones de traders, una por cada pantalla conectada. Un trader con una conexión móvil débil, o un terminal que se ha atascado, lee las actualizaciones despacio. Si el servidor espera a esa sesión, todas las demás sesiones esperan también. Dejar que la cola de actualizaciones pendientes de esa sesión crezca sin límite no es mejor, porque el servidor se queda sin memoria y cae para todos.

En un sistema bien construido, el servidor ordena las actualizaciones una sola vez y envía el mismo resultado a todas las sesiones. Una sesión que se queda atrás o bien recibe la foto más reciente del libro y se salta los pasos intermedios, o bien el servidor la desconecta indicando el motivo y la pantalla se vuelve a conectar con una copia nueva. Un feed puede romperse en más de un sitio a la vez.

¿Qué deberíamos medir antes de contratar a nadie?

Toma la hora de más actividad del último mes y reúne estas cifras de esa hora:

• Huecos: cuántas veces encontró el sistema un número de actualización que faltaba en cada feed de exchange. Si el sistema no los cuenta, ese es tu primer hallazgo
• Tiempo de recuperación: cuánto tardó cada reconstrucción y qué vieron los traders mientras tanto
• Retraso: el tiempo desde la marca de tiempo del exchange en un mensaje hasta el momento en que la actualización sale de tu servidor hacia el trader y, en unos cuantos terminales de prueba, hasta la pantalla. Toma la mediana y el percentil 99, el tiempo por debajo del cual quedan 99 de cada 100 actualizaciones. Mantén los relojes de tus servidores sincronizados con una fuente de hora precisa, o las cifras no significan nada
• Sesiones: cuántas se quedaron atrás, por cuánto, y cuántas se desconectaron, con el motivo de cada desconexión

Después graba el feed en bruto de un día de mucha actividad tal como llegó, con la hora de llegada de cada paquete. Reproducir esa grabación a velocidad real y más rápido es la prueba que planteas a cada empresa de tu lista y que repites después de cada arreglo.

¿Arreglar nuestro feed handler, comprar uno o reconstruir el fan-out?

El software que recibe el feed de un exchange y mantiene el libro se llama feed handler. Tienes tres vías, y tus mediciones deberían apuntar a una. Las dos últimas se pueden combinar.

¿Cuándo tiene sentido arreglar nuestro propio feed handler?

Arregla el feed handler que tienes cuando las mediciones apuntan a un fallo claro, como huecos que pasan desapercibidos o una reconstrucción lenta, y las personas que conocen el código siguen en la empresa.

• Cuándo encaja: un fallo que puedes señalar con precisión y un diseño que, por lo demás, funciona
• Lo que pagas: el tiempo de ingeniería y un banco de pruebas que reproduce tus grabaciones
• De quién es el código: tuyo
• El límite: un arreglo en la entrada del feed no sirve si el problema está en el envío del libro a las pantallas

¿Cuándo deberíamos comprar un feed handler o un feed gestionado?

Un feed handler ya hecho es software con licencia que se conecta a un exchange, detecta los huecos y entrega a tu sistema un libro correcto y actualizado. Un feed gestionado va más allá: un proveedor de datos de mercado se conecta a los exchanges, y tú recibes de él un solo flujo en un solo formato.

• Cuándo encaja: muchos exchanges con formatos estándar, y ningún interés en seguir cada cambio que cada exchange hace en su feed
• Lo que pagas: la licencia y el trabajo de conectar el producto con tu sistema. Las tarifas de datos y las condiciones de licencia de los propios exchanges normalmente siguen aplicándose, entregue quien entregue los datos
• Lo que sigue siendo cosa tuya: hacer llegar el libro a cientos de pantallas de traders y gestionar las sesiones lentas
• De quién es el código: el producto es del proveedor. Tuyos son la integración y todo lo que viene después

¿Cuándo deberíamos contratar a un equipo para reconstruir el fan-out?

Reconstruye la capa que envía los datos a los traders cuando la entrada del feed funciona pero el problema sigue. Los traders siguen viendo libros distintos, una sesión lenta arrastra a las demás o tienes previsto atender a muchas más sesiones que hoy.

• Cuándo encaja: el retraso crece entre tus servidores y las pantallas, no entre el exchange y tus servidores
• Lo que pagas: el tiempo de ingeniería y de pruebas, y después las personas que operan el sistema tras el lanzamiento
• De quién es el código: tuyo, si así lo dice el contrato

¿Cómo comprobamos a una empresa antes de contratarla?

Somete a cada empresa de tu lista a las mismas cinco pruebas:

• Una reproducción de tu grabación, a velocidad real y varias veces más rápido, a través de lo que la empresa entregue o muestre en una demo. Compara sus huecos, reconstrucciones, tiempos de recuperación y retrasos con los de tu sistema actual
• Cómo detecta un hueco. Una buena respuesta dice que el sistema aplica un cambio solo cuando su número es el siguiente esperado. Si falta un número, el sistema espera brevemente y después vuelve a pedir el cambio o reconstruye el libro. Hasta entonces marca el libro como desactualizado. Pregunta qué ven los traders mientras tanto
• Qué pasa con un trader lento. Pide a la empresa que ralentice a propósito una sesión durante la reproducción. Los retrasos de las demás sesiones no deberían cambiar
• Cómo mide el retraso: desde qué marca de tiempo hasta qué punto, con qué percentil, carga y hardware, y cómo se mantienen sincronizados los relojes
• De quién es el código y en qué condiciones usas las partes que la empresa conserve como propias

¿Cuáles son las señales de alarma?

• «Añadiremos más servidores» como primera respuesta, antes de que nadie haya visto tus mediciones
• «Usamos una conexión fiable, así que no se pierde nada». Binance envía sus actualizaciones por WebSocket, una conexión que no pierde datos en tránsito, y aun así su guía indica a los clientes qué hacer cuando se saltan eventos

¿Dónde encaja amBrain?

amBrain construye infraestructura de trading algorítmico: ejecución de órdenes, datos de mercado y controles de riesgo pre-trade.

Una línea del sitio web de amBrain dice: «Desarrollo de terminales de trading, sistemas de gestión de órdenes e integración con exchanges por protocolo FIX».

amBrain diagnostica sistemas lentos en trading y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo.

amBrain desarrolla software desde 2019. Describe a su equipo en una línea: «Un equipo de hasta 40 personas, alrededor del 75% de ellas senior». Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. El cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain.

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes. No cita cifras de latencia de ningún sistema construido por amBrain, ni precios ni plazos.

Si amBrain está en tu lista corta, hazle las mismas cinco preguntas que a cualquier otra empresa, y convierte tu grabación en el criterio de aprobación de cualquier trabajo que acuerdes con ella.

Preguntas frecuentes

• ¿Lo arreglarán más servidores? No por sí solos. Si el sistema aplica los cambios fuera de orden o espera a su sesión más lenta, más servidores repiten el mismo fallo. Añade servidores cuando las mediciones muestren que los actuales se están quedando sin capacidad
• ¿Podemos combinar actualizaciones y enviar menos? Para el libro de órdenes, sí. Los ingenieros lo llaman conflation, y algunos exchanges lo hacen ellos mismos. La documentación de Binance fija la velocidad de actualización de su flujo spot de cambios del libro de órdenes en 1000 ms o 100 ms. Avisa a los traders de que el flujo muestra la foto más reciente, no cada paso. No combines las operaciones ni las confirmaciones de órdenes, porque descartar una deja mal el historial de operaciones
• ¿Tenemos que reescribirlo en Rust o C++? No necesariamente. Los huecos que pasan desapercibidos y un servidor que espera a su sesión más lenta son fallos de diseño que un lenguaje nuevo no elimina. Rust y C++ no tienen recolector de basura, la limpieza automática de memoria que puede pausar un programa escrito en un lenguaje como Java o Go. Eso ayuda en las partes del sistema que procesan cada actualización. Sea cual sea el lenguaje, pide el retraso medido en el pico
• ¿Cuánto tarda un arreglo? Depende de dónde esté el fallo y de cuántos exchanges y sesiones tengas. Pide a cada empresa que presupueste y planifique una primera fase que cubra las mediciones y un entorno de pruebas que reproduzca tu grabación. Usa las cinco pruebas de arriba como criterios de aprobación