Comunicación de datos en sistemas de trading algorítmico: una visión general de la tecnología

En el trading algorítmico, la diferencia entre ganancia y pérdida puede medirse en microsegundos. La arquitectura de transmisión de datos es uno de los factores clave que determinan la eficiencia de un sistema de trading. En este artículo desglosamos las tecnologías de comunicación en todos los niveles: desde la interacción con el exchange hasta la comunicación interna entre servicios, el almacenamiento y la distribución de datos.

El artículo está organizado por niveles —desde lo "externo" (protocolos del exchange) hasta lo "interno" (IPC, brokers de mensajería, almacenamiento)— reflejando la arquitectura real de una plataforma de trading algorítmico.

1. Interacción con el exchange: REST, WebSocket, FIX

1.1 API REST

REST es la forma más sencilla y común de interactuar con la API de un exchange. Cada solicitud es una conexión HTTP independiente: handshake TCP → handshake TLS → enviar solicitud → recibir respuesta → cerrar conexión.

Problemas de REST para el trading:

Cada solicitud conlleva la sobrecarga de establecer la conexión. Incluso con HTTP keep-alive, el modelo "solicitud-respuesta" implica que no se pueden recibir datos más rápido de lo que se envían solicitudes. Esto lleva al polling: un ciclo infinito de preguntas del tipo "¿hay datos nuevos?" que, según desarrolladores de exchanges de criptomonedas, generan hasta el 80 % de la carga en los servidores del exchange. Los exchanges imponen límites de tasa (típicamente entre 10 y 1200 solicitudes por minuto), lo que hace que REST sea inadecuado para estrategias de alta frecuencia.

Cuándo REST es apropiado: obtención de datos históricos (velas, OHLCV), gestión de la cuenta (saldo, posiciones), operaciones que no son en tiempo real (bots de DCA, rebalanceo cada hora).

1.2 WebSocket

WebSocket establece una única conexión TCP persistente por la que los datos fluyen de forma bidireccional. Comienza como una solicitud HTTP normal con un encabezado Upgrade y luego cambia a un protocolo de framing bidireccional (la carga útil puede ser JSON de texto o binaria).

Ventajas para el trading:

La principal ventaja es que no hay sobrecarga por solicitud. Una vez establecida la conexión, el servidor envía los datos de forma instantánea. La latencia de entrega de datos de mercado a través de WebSocket suele ser inferior a 50 ms desde el gateway del exchange hasta el cliente. Se pueden suscribir 50 o más símbolos simultáneamente a través de una sola conexión.

Un punto crítico: las órdenes a través de WebSocket. Muchos traders no saben que algunos exchanges (Binance, HitBTC, Deribit, Bybit, etc.) permiten enviar órdenes a través de WebSocket, no solo recibir datos. Esto es fundamentalmente más rápido que REST porque:

• No hay handshake TCP/TLS para cada orden (la conexión ya está "caliente")
• No hay sobrecarga HTTP (encabezados, cookies, etc.)
• Modelo asíncrono: se envía una orden y se recibe la confirmación por el mismo WebSocket sin bloquear el hilo.

Según Deribit, WebSocket y FIX suelen tener la misma velocidad de ejecución. REST es ligeramente más lento debido al preprocesamiento a nivel de conexión. Las órdenes vía WebSocket llegan a la cola del motor de emparejamiento igual que las órdenes FIX.

El problema de la mezcla de contextos. Si se envían órdenes por REST pero se reciben las notificaciones de ejecución por WebSocket, se produce una condición de carrera: la notificación de WebSocket puede llegar antes de que se complete la solicitud REST. Esto provoca inconsistencia de estado. La solución consiste en enviar las órdenes por el mismo WebSocket, pasando por completo a un modelo asíncrono.

1.3 Protocolo FIX (Financial Information eXchange)

FIX es el estándar industrial para el trading electrónico, existente desde 1992 (creado por Fidelity Investments y Salomon Brothers). Es un protocolo binario sobre TCP diseñado específicamente para el trading.

Arquitectura de FIX:

• Capa de sesión — gestiona la conexión, los heartbeats, la numeración de secuencia, la recuperación de huecos. Garantiza la entrega y el orden de los mensajes.
• Capa de aplicación — lógica de negocio: tipos de órdenes, informes de ejecución, solicitudes de datos de mercado.

Los mensajes FIX consisten en pares "tag=value" separados por un carácter SOH. Por ejemplo, una orden de compra de 100 acciones de AAPL a 150 $ se ve así:

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

Por qué FIX es más rápido que WebSocket: FIX es un protocolo TCP nativo sin capas HTTP. AWS, en su guía de optimización tick-to-trade para exchanges de criptomonedas, recomienda explícitamente FIX sobre REST y WebSocket para minimizar la latencia inducida por el protocolo. FIX opera a nivel de microsegundos, mientras que WebSocket suele estar en el rango de milisegundos.

Dónde domina FIX: DMA (Direct Market Access) al motor de emparejamiento del exchange, trading algorítmico y HFT en ámbitos institucionales, agregación de liquidez (prime brokers conectándose a docenas de bancos vía FIX).

Limitaciones de FIX: complejidad de integración, formato de mensaje anticuado (los pares de texto tag-value son menos eficientes que los formatos binarios), alta barrera de entrada. En la industria cripto, FIX solo lo soportan un número limitado de exchanges.

1.4 SBE (Simple Binary Encoding) — La evolución de FIX

SBE es un formato de serialización binaria creado por el High Performance Working Group dentro de la FIX Trading Community. Su misión es reemplazar el formato de texto de FIX por una representación binaria compacta para el trading de ultra baja latencia.

Principios clave de SBE:

• Patrón flyweight de copia cero (zero-copy) — los codificadores y decodificadores actúan como "plantillas" sobre un buffer. Los valores se escriben directamente sin copias intermedias (a diferencia de Protobuf, que requiere varias).
• El formato en el cable = el formato en memoria — los datos en el cable se ven igual que en memoria, minimizando la sobrecarga de transformación.
• Campos fijos primero, campos variables al final — una restricción de diseño que ofrece un orden de magnitud más de rendimiento en comparación con Protocol Buffers.

SBE + Aeron es la combinación estándar para sistemas de trading de alto rendimiento. Aeron es un sistema de mensajería de código abierto de Real Logic (creado por Martin Thompson, ex CTO de LMAX Exchange, y Todd Montgomery, ex CTO de 29West/Ultra Messaging). Es, en esencia, una capa de transporte especializada para sistemas financieros que funciona sobre UDP y memoria compartida con latencias de un solo dígito de microsegundos. SBE se encarga de la serialización, mientras que Aeron gestiona la entrega con retrasos de microsegundos. Más sobre Aeron en la sección 3.1.

1.5 Tabla comparativa de protocolos de exchange

2. Comunicación interna entre microservicios

Una vez que los datos entran al sistema desde el exchange, comienza el procesamiento interno: parsing → estrategia → decisión → envío de la orden. En cada paso hay comunicación entre servicios.

2.1 gRPC con streaming bidireccional (TCP)

gRPC es un framework de Google basado en HTTP/2 que utiliza Protocol Buffers para la serialización. Para el trading algorítmico, el streaming bidireccional es especialmente importante: cuando el cliente y el servidor envían simultáneamente flujos de mensajes por una misma conexión.

Por qué gRPC encaja en los sistemas de trading:

• Protobuf es compacto (de 3 a 10 veces más pequeño que JSON)
• Multiplexación HTTP/2 — varios streams sobre una sola conexión TCP
• Tipado estricto mediante esquemas .proto que detecta errores en tiempo de compilación
• Generación de código para Python, Rust, Go, C++, Java, etc.
• El streaming bidireccional permite el patrón "datos de mercado hacia abajo, órdenes hacia arriba" por un solo canal.

Según SmartDev, el 70 % de las instituciones financieras que despliegan HFT impulsado por IA usan gRPC o TCP puro para tiempos de respuesta de microsegundos.

Ejemplo de arquitectura: Market Data Collector (Rust) → stream gRPC → Strategy Engine (Python/Rust) → llamada gRPC → Order Router (Rust) → WebSocket/FIX → Exchange.

2.2 gRPC vía Unix Domain Socket (UDS)

Si los servicios se ejecutan en la misma máquina (típico en co-ubicación), TCP es una sobrecarga innecesaria. Unix Domain Socket (UDS) evita toda la pila de red: sin handshake TCP, sin enrutamiento, sin cálculo de checksums.

Los benchmarks muestran una diferencia significativa:

• gRPC vía UDS: ~102 μs/solicitud (100 000 solicitudes)
• gRPC vía TCP: ~127 μs/solicitud (100 000 solicitudes)
• Ganancia con UDS: ~20 % en mensajes pequeños, hasta un 50 % en mensajes grandes (100 KB+).

Según F. Werner (MPI Heidelberg), al comparar gRPC UDS con I/O bloqueante puro vía UDS, gRPC añade aproximadamente 10 veces más sobrecarga: mediana de ~130 μs frente a ~13 μs para UDS puro. Este es el costo de la abstracción (framing de HTTP/2, serialización de protobuf).

Cuándo usar gRPC+UDS: comunicación entre procesos en un solo servidor, cuando se valora más la comodidad del desarrollador (esquema, codegen) que la latencia absolutamente mínima. UDS también ofrece ventajas de seguridad a través de los permisos de archivos de Unix.

Cuándo NO usarlo: si se necesita una latencia inferior a 10 μs, la memoria compartida o el UDS puro sin gRPC son mejores opciones. Como referencia: la mediana del UDS puro es de ~13 μs, la del gRPC UDS de ~130 μs. La memoria compartida (Aeron IPC) está por debajo de 1 μs, y el anillo de búfer de LMAX Disruptor ronda los 50–100 ns. Así, gRPC+UDS es unas 10 veces más lento que el UDS puro y de 100 a 1000 veces más lento que la memoria compartida. Pero cada paso hacia abajo en latencia es un paso hacia arriba en complejidad de código.

Reprodúzcalo usted mismo: todas las cifras de latencia de IPC de esta sección son reproducibles con el benchmark complementario de código abierto suenot/trading-ipc-bench — implementaciones en Python de idas y vueltas por TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, memoria compartida y Named Pipe, midiendo la latencia p50/p95/p99/p99.9 y el rendimiento en su propio hardware.

UDS puro sin gRPC — si la sobrecarga de gRPC es excesiva, elimínela y conserve solo el socket. Opciones en orden decreciente de rendimiento:

• Sockets AF_UNIX + serialización personalizada (SBE, FlatBuffers, MessagePack) — mediana de ~13 μs, máximo control, máxima complejidad
• ZeroMQ IPC (ipc://) — ~50–100 μs, patrones ya hechos (PUB/SUB, REQ/REP) sin código repetitivo, usa UDS por debajo
• IPC de nanomsg/NNG — similar a ZeroMQ, latencia ligeramente mejor en mensajes pequeños (<64 KB)
• RPC de Cap'n Proto sobre UDS — serialización de copia cero + abstracción RPC, más rápido que gRPC, con esquema

2.3 IPC de memoria compartida

Para una latencia ultra baja en el mismo host, se usa memoria compartida. Dos procesos mapean el mismo segmento de RAM y los datos se transmiten sin llamadas al sistema (excepto en la configuración inicial).

El patrón LMAX Disruptor (anillo de búfer en memoria compartida) gestiona ~6 millones de eventos por segundo en un solo hilo. Este enfoque es el corazón de LMAX Exchange y de muchos sistemas HFT.

Implementaciones: Aeron IPC (Java/C++), Chronicle Queue (Java), soluciones personalizadas basadas en mmap (Rust/C++). IronSBE (una implementación de SBE en Rust) soporta IPC de memoria compartida con una latencia de ~20 ns a nivel del canal SPSC.

3. Sistemas de transporte: brokers de mensajería y bibliotecas

3.1 Aeron — El estándar de oro

Aeron es un sistema de transporte de mensajes de código abierto y alto rendimiento desarrollado por Real Logic. Sus creadores son Martin Thompson (ex CTO de LMAX) y Todd Montgomery (ex CTO de 29West). Comenzó en 2014 para un importante exchange estadounidense y ahora cuenta con más de 70 contribuidores y más de 5000 suscriptores en GitHub.

En la práctica: Aeron no es un broker (como Kafka) ni una biblioteca de sockets (como ZeroMQ). Es una capa de transporte diseñada para una latencia baja y predecible. Funciona sobre UDP (red) y memoria compartida (IPC), proporcionando entrega fiable, ordenación y control de flujo, cosas de las que carece el UDP puro. Se puede pensar en Aeron como "TCP con la latencia de UDP".

Características de Aeron:

• Latencia: <100 μs en la nube, <18 μs en bare metal.
• Rendimiento: >1 millón de mensajes/s con latencia de microsegundos.
• Pico de más de 20 millones de mensajes/s.
• Sin broker (brokerless) — sin punto único de fallo.
• Soporta unicast, multicast e IPC.
• Control de flujo y detección de pérdidas integrados.

Aeron Cluster — replicación tolerante a fallos de máquina de estados (consenso Raft) para una lógica de trading consistente con una latencia añadida mínima.

Aeron Archive — persistencia de mensajes a la velocidad completa del stream, con capacidad de repetición.

Aeron Sequencer — el componente más reciente del ecosistema, diseñado para coordinar múltiples proyectos en grandes organizaciones. Construido sobre Aeron Transport y Aeron Cluster. Características clave:

• Log distribuido — una larga secuencia de mensajes replicada en varias máquinas para tolerancia a fallos
• Múltiples lectores — varias aplicaciones leen simultáneamente del mismo log con fines diferentes
• Equipos desacoplados — los equipos permanecen independientes mientras operan dentro de un único sistema coordinado
• Casos de uso objetivo: procesamiento de datos de mercado, plataformas de brokers, motores de exchange

Comparación con Kafka: ambos usan un log distribuido, pero Aeron está pensado para latencia de microsegundos, mientras que Kafka lo está para durabilidad y rendimiento en milisegundos. Aeron existe para la lógica en tiempo real; Kafka, para pipelines de datos y analítica.

3.2 Apache Kafka

Apache Kafka es el estándar de facto para el streaming de eventos a gran escala. No es para el camino crítico de trading (retrasos de milisegundos), pero es indispensable para:

• Agregación de datos de mercado: recopilar flujos de más de 100 exchanges en una sola pipeline.
• Event sourcing: registrar cada acción del sistema como un topic de eventos.
• CDC (Change Data Capture): transmitir los cambios de la base de datos de trading hacia la analítica.
• Integración con QuestDB: Kafka → QuestDB para analítica de ticks en tiempo real.

La latencia es de 2 a 15 ms de extremo a extremo. Inaceptable para HFT, pero adecuada para estrategias con un horizonte superior a 1 segundo.

3.3 Redis Pub/Sub y Streams

Redis es un almacén en memoria que también funciona como broker ligero.

Redis Pub/Sub — de tipo fire-and-forget; latencia inferior al milisegundo. Ideal para notificaciones en tiempo real: actualizaciones de precios, señales de estrategia, alertas.

Redis Streams — añade persistencia y grupos de consumidores (un mini-Kafka). Permite leer el historial y confirmaciones (ACK).

Redis es más rápido que Kafka para mensajes pequeños (por debajo del milisegundo), pero carece de la replicación y la durabilidad robustas de Kafka.

3.4 NATS

NATS es un sistema ultraligero escrito en Go. Latencia por debajo del milisegundo, pub/sub integrado, request/reply. NATS JetStream añade persistencia y entrega exactamente una vez.

3.5 ZeroMQ y nanomsg

Bibliotecas sin broker que ofrecen abstracciones de socket para comunicación punto a punto. ZeroMQ gestiona más de 5 millones de mensajes/s y ha sido probado en producción desde 2007. nanomsg (y NNG) es su "sucesor", con mejor latencia en mensajes pequeños (<64 KB).

4. PUB/SUB en tiempo real para clientes: Centrifugo

Centrifugo es un servidor PUB/SUB autoalojado escrito en Go, optimizado para la difusión a miles o millones de clientes vía WebSocket, SSE o gRPC.

Por qué Centrifugo para el algo trading:

• Gestiona 1 millón de conexiones WebSocket y 30 millones de mensajes/min en un solo servidor.
• Soporta streaming a 60 Hz.
• Compresión delta (algoritmo Fossil) para minimizar el tráfico.
• Perfecto para la "última milla" hacia dashboards web o aplicaciones móviles.

5. Almacenes de datos de acceso en tiempo real

5.1 QuestDB — Series temporales para el trading

QuestDB es una base de datos de series temporales de código abierto escrita en Java (zero-GC), C++ y Rust.

• Consultas: ejecución vectorizada por debajo del milisegundo mediante SIMD.
• SAMPLE BY/ASOF JOIN: extensiones SQL nativas y amigables para traders.
• WAL: anexado (append) de ultra baja latencia.
• Utilizado por B3 (la bolsa de valores de Brasil).

5.2 Redis como capa de datos

Normalmente actúa como una capa intermedia:

• Caché caliente para el acceso a precios en O(1).
• Sorted sets para libros de órdenes.
• Scripts Lua para operaciones atómicas.

5.3 Soluciones especializadas: RayforceDB, AXL DB

Bases de datos vectoriales minimalistas basadas en C (binarios de menos de 1 MB), sin dependencias y con aceleración SIMD. Se centran en la latencia determinista para HFT.

6. Serialización: Protobuf vs. SBE vs. JSON

7. Arquitecturas de referencia

7.1 Arbitraje de criptomonedas (frecuencia media)

Exchanges → Collector (Rust) → Redis (Hot) → Estrategia (Python) → gRPC → Router (Rust) → Exchange.

7.2 Market making de HFT (co-ubicación)

Feed del exchange → NIC con kernel bypass → Aeron IPC → Estrategia (C++) → SBE → Aeron → Exchange.

8. Consejos prácticos

• <10 μs (HFT): FPGA, memoria compartida, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (frecuencia media): WebSocket, Kafka, Redis.
• >10 ms (baja frecuencia / swing): la API REST es suficiente. DCA, rebalanceo, gestión de cartera.

No optimice lo que no es un cuello de botella. Si su estrategia tarda 50 ms en decidir, el ahorro de 100 μs de Aeron no importará. Las arquitecturas híbridas son normales: use REST para la configuración, gRPC como núcleo y WS para la entrega.

Repositorio de benchmarks

Las cifras de latencia citadas a lo largo de este artículo se pueden reproducir con suenot/trading-ipc-bench — un conjunto de benchmarks en Python de código abierto que cubre todos los transportes IPC principales aquí discutidos: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub y memoria compartida.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # runs all 8 transports, saves results to results/
python report.py    # prints a summary table + ASCII latency chart

Ejecútelo en su propio hardware; los resultados diferirán de las cifras de este artículo según su CPU, sistema operativo, versión del kernel y ajustes. Ese es precisamente el objetivo.

Conclusión

No existe una tecnología de comunicación "perfecta". Cada nivel tiene requisitos únicos: externo (compatibilidad), interno (latencia), pipeline (fiabilidad) y cliente (flexibilidad). La arquitectura consiste en elegir la herramienta adecuada para el trabajo específico.