Comunicação de Dados em Sistemas de Algo Trading: Uma Visão Geral Tecnológica

Na negociação algorítmica, a diferença entre lucro e prejuízo pode ser medida em microssegundos. A arquitetura de transmissão de dados é um dos fatores-chave que determinam a eficiência de um sistema de negociação. Neste artigo, vamos analisar as tecnologias de comunicação em todos os níveis: da interação com a exchange até a comunicação interna entre serviços, armazenamento e distribuição de dados.

O artigo está organizado por níveis—do "externo" (protocolos de exchange) ao "interno" (IPC, message brokers, armazenamento)—refletindo a arquitetura real de uma plataforma de negociação algorítmica.

1. Interação com a Exchange: REST, WebSocket, FIX

1.1 API REST

REST é a forma mais simples e comum de interagir com a API de uma exchange. Cada requisição é uma conexão HTTP separada: handshake TCP → handshake TLS → enviar requisição → receber resposta → fechar conexão.

Problemas do REST para Trading:

Cada requisição carrega o overhead de estabelecer a conexão. Mesmo com HTTP keep-alive, o modelo "requisição-resposta" significa que você não pode receber dados mais rápido do que envia requisições. Isso leva ao polling—um ciclo infinito de perguntas "há dados novos?" que geram até 80% da carga nos servidores das exchanges (segundo desenvolvedores de exchanges de cripto). As exchanges introduzem limites de taxa (tipicamente 10–1200 requisições por minuto), tornando o REST inadequado para estratégias de alta frequência.

Quando o REST é apropriado: obtenção de dados históricos (candles, OHLCV), gerenciamento de conta (saldo, posições), operações que não são em tempo real (bots de DCA, rebalanceamento por hora).

1.2 WebSocket

O WebSocket estabelece uma única conexão TCP persistente através da qual os dados fluem de forma bidirecional. Começa como uma requisição HTTP normal com um cabeçalho Upgrade, depois muda para um protocolo de enquadramento bidirecional (o payload pode ser texto JSON ou binário).

Vantagens para Trading:

A principal vantagem é a ausência de overhead por requisição. Uma vez estabelecida a conexão, os dados são enviados instantaneamente pelo servidor. A latência de entrega de dados de mercado via WebSocket é tipicamente inferior a 50 ms desde o gateway da exchange até o cliente. Você pode se inscrever em mais de 50 símbolos simultaneamente em uma única conexão.

Um ponto crítico: ordens via WebSocket. Muitos traders não sabem que algumas exchanges (Binance, HitBTC, Deribit, Bybit, etc.) permitem o envio de ordens via WebSocket, não apenas o recebimento de dados. Isso é fundamentalmente mais rápido que o REST porque:

• Não há handshake TCP/TLS para cada ordem (a conexão já está "quente")
• Não há overhead de HTTP (cabeçalhos, cookies, etc.)
• É um modelo assíncrono: você envia uma ordem e recebe confirmação através do mesmo WebSocket sem bloquear a thread.

Segundo a Deribit, WebSocket e FIX frequentemente têm a mesma velocidade de execução. O REST é ligeiramente mais lento devido ao pré-processamento no nível da conexão. As ordens via WebSocket entram na fila do motor de matching assim como as ordens FIX.

Problema de Mistura de Contexto. Se você envia ordens via REST mas recebe notificações de execução via WebSocket, ocorre uma condição de corrida: a notificação do WebSocket pode chegar antes que a requisição REST se complete. Isso leva a uma inconsistência de estado. A solução é enviar as ordens através do mesmo WebSocket, migrando completamente para um modelo assíncrono.

1.3 Protocolo FIX (Financial Information eXchange)

FIX é o padrão industrial para negociação eletrônica, existente desde 1992 (criado por Fidelity Investments e Salomon Brothers). É um protocolo binário sobre TCP projetado especificamente para negociação.

Arquitetura do FIX:

• Camada de sessão — gerencia a conexão, heartbeats, numeração de sequência, recuperação de lacunas. Garante a entrega e a ordem das mensagens.
• Camada de aplicação — lógica de negócio: tipos de ordem, relatórios de execução, requisições de dados de mercado.

As mensagens FIX consistem em pares "tag=valor" separados por um caractere SOH. Por exemplo, uma ordem de compra de 100 ações da AAPL a $150 se parece com isto:

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

Por que o FIX é mais rápido que o WebSocket: o FIX é um protocolo TCP nativo sem camadas HTTP. A AWS, em seu guia de otimização tick-to-trade para exchanges de cripto, recomenda explicitamente o FIX em vez de REST e WebSocket para minimizar a latência induzida pelo protocolo. O FIX opera no nível de microssegundos, enquanto o WebSocket está tipicamente em milissegundos.

Onde o FIX domina: DMA (Direct Market Access) para o motor de matching da exchange, negociação algorítmica e HFT em ambientes institucionais, agregação de liquidez (prime brokers conectando-se a dezenas de bancos via FIX).

Limitações do FIX: complexidade de integração, formato de mensagem desatualizado (os tag-values textuais são menos eficientes que formatos binários), alta barreira de entrada. Na indústria de criptomoedas, o FIX é suportado por um número limitado de exchanges.

1.4 SBE (Simple Binary Encoding) — FIX Evolutivo

SBE é um formato de serialização binária criado pelo High Performance Working Group dentro da FIX Trading Community. Sua missão é substituir o formato textual do FIX por uma representação binária compacta para negociação de ultra-baixa latência.

Princípios-chave do SBE:

• Padrão flyweight zero-copy — codificadores e decodificadores atuam como "templates" sobre um buffer. Os valores são escritos diretamente sem cópias intermediárias (diferente do Protobuf, que exige várias).
• Formato de transmissão = formato de memória — os dados na rede se parecem exatamente como na memória, minimizando o overhead de transformação.
• Campos fixos primeiro, campos variáveis por último — uma restrição de design que gera uma ordem de grandeza a mais de desempenho comparado ao Protocol Buffers.

SBE + Aeron é a combinação padrão para sistemas de negociação de alto desempenho. Aeron é um sistema de mensageria open source da Real Logic (criado por Martin Thompson, ex-CTO da LMAX Exchange, e Todd Montgomery, ex-CTO da 29West/Ultra Messaging). É efetivamente uma camada de transporte especializada para sistemas financeiros que funciona sobre UDP e memória compartilhada com latências de microssegundos de dígito único. O SBE cuida da serialização, enquanto o Aeron gerencia a entrega com atrasos em microssegundos. Mais sobre o Aeron na seção 3.1.

1.5 Tabela Comparativa de Protocolos de Exchange

2. Comunicação Interna entre Microsserviços

Assim que os dados entram no sistema vindos da exchange, começa o processamento interno: parsing → estratégia → decisão → envio da ordem. Em cada etapa, há comunicação entre serviços.

2.1 gRPC Streaming Bidirecional (TCP)

gRPC é um framework do Google baseado em HTTP/2 que usa Protocol Buffers para serialização. Para negociação algorítmica, o streaming bidirecional é particularmente importante—quando cliente e servidor enviam simultaneamente fluxos de mensagens através de uma única conexão.

Por que o gRPC se adequa a sistemas de negociação:

• O Protobuf é compacto (3 a 10 vezes menor que o JSON)
• Multiplexação HTTP/2 — vários fluxos sobre uma única conexão TCP
• Tipagem estrita via esquemas .proto que capturam erros em tempo de compilação
• Geração de código para Python, Rust, Go, C++, Java, etc.
• O streaming bidirecional permite o padrão "dados de mercado descendo, ordens subindo" através de um único canal.

Segundo a SmartDev, 70% das instituições financeiras que implantam HFT baseado em IA usam gRPC ou TCP puro para tempos de resposta em microssegundos.

Exemplo de arquitetura: Market Data Collector (Rust) → stream gRPC → Strategy Engine (Python/Rust) → chamada gRPC → Order Router (Rust) → WebSocket/FIX → Exchange.

2.2 gRPC via Unix Domain Socket (UDS)

Se os serviços rodam na mesma máquina (típico em co-location), o TCP é um overhead desnecessário. O Unix Domain Socket (UDS) contorna toda a pilha de rede: sem handshake TCP, sem roteamento, sem checksum.

Os benchmarks mostram uma diferença significativa:

• gRPC via UDS: ~102 μs/requisição (100 mil requisições)
• gRPC via TCP: ~127 μs/requisição (100 mil requisições)
• Ganho do UDS: ~20% em mensagens pequenas, até 50% em mensagens grandes (100 KB+).

Segundo F. Werner (MPI Heidelberg), comparando gRPC UDS com I/O bloqueante puro via UDS, o gRPC adiciona cerca de 10x de overhead—mediana de ~130 μs contra ~13 μs para UDS puro. Esse é o custo da abstração (enquadramento HTTP/2, serialização protobuf).

Quando usar gRPC+UDS: Comunicação entre processos em um único servidor, quando a conveniência para o desenvolvedor (esquema, geração de código) é valorizada em detrimento da latência mínima absoluta. O UDS também oferece vantagens de segurança através de permissões de arquivo do Unix.

Quando NÃO usar: Se você precisa de latência <10 μs, memória compartilhada ou UDS puro sem gRPC são melhores. Para referência: UDS puro mediana ~13 μs, gRPC UDS mediana ~130 μs. Memória compartilhada (Aeron IPC) fica abaixo de 1 μs, o ring buffer do LMAX Disruptor fica em torno de 50–100 ns. Portanto, gRPC+UDS é ~10x mais lento que UDS puro e 100–1000x mais lento que memória compartilhada. Mas cada passo a menos em latência é um passo a mais em complexidade de código.

Reproduza você mesmo: Todos os números de latência de IPC apresentados nesta seção são reprodutíveis com o benchmark complementar de código aberto suenot/trading-ipc-bench — implementações em Python de TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Memória Compartilhada e round-trips de Named Pipe, medindo latência p50/p95/p99/p99.9 e throughput no seu próprio hardware.

UDS puro sem gRPC — se o overhead do gRPC for excessivo, remova-o e mantenha apenas o socket. Opções em ordem decrescente de desempenho:

• Sockets AF_UNIX + serialização personalizada (SBE, FlatBuffers, MessagePack) — ~13 μs mediana, controle máximo, complexidade máxima
• ZeroMQ IPC (ipc://) — ~50–100 μs, padrões prontos (PUB/SUB, REQ/REP) sem boilerplate, usa UDS por baixo dos panos
• nanomsg/NNG IPC — semelhante ao ZeroMQ, latência ligeiramente melhor em mensagens pequenas (<64 KB)
• Cap'n Proto RPC sobre UDS — serialização zero-copy + abstração RPC, mais rápido que o gRPC, possui esquema

2.3 IPC de Memória Compartilhada

Para latência ultra-baixa no mesmo host, use memória compartilhada. Dois processos mapeiam o mesmo segmento de RAM, e os dados passam sem syscalls (exceto na configuração inicial).

O padrão LMAX Disruptor (ring buffer em memória compartilhada) processa ~6 milhões de eventos por segundo em uma única thread. Essa abordagem é o coração da LMAX Exchange e de muitos sistemas de HFT.

Implementações: Aeron IPC (Java/C++), Chronicle Queue (Java), soluções personalizadas baseadas em mmap (Rust/C++). O IronSBE (implementação de SBE em Rust) suporta IPC de memória compartilhada com latência de ~20 ns no nível de canal SPSC.

3. Sistemas de Transporte: Message Brokers e Bibliotecas

3.1 Aeron — O Padrão Ouro

Aeron é um sistema de transporte de mensagens de alto desempenho e código aberto desenvolvido pela Real Logic. Seus criadores são Martin Thompson (ex-CTO da LMAX) e Todd Montgomery (ex-CTO da 29West). Começou em 2014 para uma grande exchange dos EUA e agora conta com mais de 70 colaboradores e mais de 5000 seguidores no GitHub.

Na prática: o Aeron não é um broker (como o Kafka) nem uma biblioteca de sockets (como o ZeroMQ). É uma camada de transporte projetada para latência baixa e previsível. Funciona sobre UDP (rede) e memória compartilhada (IPC), oferecendo entrega confiável, ordenação e controle de fluxo—coisas que o UDP puro não possui. Pense no Aeron como "TCP com a latência do UDP".

Características do Aeron:

• Latência: <100 μs na nuvem, <18 μs em bare metal.
• Throughput: >1M mensagens/s com latência em microssegundos.
• Pico de 20M+ mensagens/s.
• Sem broker — nenhum ponto único de falha.
• Suporta unicast, multicast e IPC.
• Controle de fluxo e detecção de perda embutidos.

Aeron Cluster — replicação de máquina de estados tolerante a falhas (consenso Raft) para lógica de negociação consistente com latência adicional mínima.

Aeron Archive — persistência de mensagens na velocidade total do fluxo, com capacidade de replay.

Aeron Sequencer — o componente mais recente do ecossistema, projetado para coordenar múltiplos projetos em grandes organizações. Construído sobre o Aeron Transport e o Aeron Cluster. Características principais:

• Log distribuído — uma longa sequência de mensagens replicada em várias máquinas para tolerância a falhas
• Múltiplos leitores — várias aplicações leem simultaneamente do mesmo log para diferentes finalidades
• Equipes desacopladas — as equipes permanecem independentes enquanto operam dentro de um único sistema coordenado
• Casos de uso alvo: processamento de dados de mercado, plataformas de brokers, motores de exchange

Comparação com o Kafka: ambos usam um log distribuído, mas o Aeron é para latência em microssegundos, enquanto o Kafka é para durabilidade e throughput em milissegundos. O Aeron existe para lógica em tempo real; o Kafka, para pipelines de dados e análises.

3.2 Apache Kafka

O Apache Kafka é o padrão de fato para streaming de eventos em escala. Não é para o hot path da negociação (atrasos em milissegundos), mas é indispensável para:

• Agregação de dados de mercado: coletar fluxos de mais de 100 exchanges em um único pipeline.
• Event sourcing: registrar cada ação do sistema como um tópico de evento.
• CDC (Change Data Capture): transmitir mudanças no banco de dados de negociação para análise.
• Integração com QuestDB: Kafka → QuestDB para análise de ticks em tempo real.

A latência é de 2 a 15 ms de ponta a ponta. Inaceitável para HFT, mas adequada para estratégias com horizonte >1s.

3.3 Redis Pub/Sub e Streams

O Redis é um armazenamento em memória que também funciona como um broker leve.

Redis Pub/Sub — dispara e esquece (fire-and-forget); latência sub-milissegundo. Ideal para notificações em tempo real: atualizações de preço, sinais de estratégia, alertas.

Redis Streams — adiciona persistência e grupos de consumidores (mini-Kafka). Suporta leitura de histórico e ACKs.

O Redis é mais rápido que o Kafka para mensagens pequenas (sub-ms), mas carece da replicação e durabilidade robustas do Kafka.

3.4 NATS

O NATS é um sistema ultraleve escrito em Go. Latência sub-ms, pub/sub embutido, request/reply. O NATS JetStream adiciona persistência e entrega exactly-once.

3.5 ZeroMQ e nanomsg

Bibliotecas sem broker que fornecem abstrações de socket para comunicação ponto a ponto. O ZeroMQ processa mais de 5M mensagens/s e é testado em produção desde 2007. O nanomsg (e o NNG) é seu "sucessor", com latência melhor em mensagens pequenas (<64 KB).

4. PUB/SUB em Tempo Real para Clientes: Centrifugo

O Centrifugo é um servidor PUB/SUB self-hosted em Go, otimizado para transmitir para milhares/milhões de clientes via WebSocket, SSE ou gRPC.

Por que o Centrifugo para Algo Trading:

• Suporta 1M de conexões WebSocket e 30M de mensagens/min em um único servidor.
• Suporta streaming a 60Hz.
• Compressão delta (algoritmo Fossil) para minimizar o tráfego.
• Perfeito para a "última milha" até dashboards web ou aplicativos móveis.

5. Armazenamentos de Dados de Acesso em Tempo Real

5.1 QuestDB — Série Temporal para Trading

O QuestDB é um banco de dados de séries temporais open source escrito em Java (zero-GC), C++ e Rust.

• Consultas: execução vetorizada sub-ms via SIMD.
• SAMPLE BY/ASOF JOIN: extensões SQL nativas amigáveis para traders.
• WAL: anexação (append) de latência ultra-baixa.
• Usado pela B3 (a bolsa de valores do Brasil).

5.2 Redis como Camada de Dados

Tipicamente uma camada intermediária:

• Cache quente para acesso a preços em O(1).
• Sorted sets para livros de ordens.
• Scripts Lua para operações atômicas.

5.3 Soluções Especializadas: RayforceDB, AXL DB

Bancos de dados vetoriais minimalistas baseados em C (binário <1MB), sem dependências e com aceleração SIMD. Foco em latência determinística para HFT.

6. Serialização: Protobuf vs SBE vs JSON

7. Arquiteturas de Referência

7.1 Arbitragem de Criptomoedas (Frequência Média)

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

7.2 HFT Market Making (Co-location)

Exchange Feed → Kernel Bypass NIC → Aeron IPC → Strategy (C++) → SBE → Aeron → Exchange.

8. Conselhos Práticos

• <10 μs (HFT): FPGA, memória compartilhada, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Frequência Média): WebSocket, Kafka, Redis.
• >10 ms (Baixa Frequência / Swing): a API REST é suficiente. DCA, rebalanceamento, gestão de portfólio.

Não otimize o que não é um gargalo. Se a sua estratégia leva 50 ms para decidir, a economia de 100 μs do Aeron não fará diferença. Arquiteturas híbridas são normais: use REST para configuração, gRPC para o coração e WS para a entrega.

Repositório de Benchmark

Os números de latência citados ao longo deste artigo podem ser reproduzidos com o suenot/trading-ipc-bench — um conjunto de benchmarks Python de código aberto que cobre todos os principais transportes IPC discutidos aqui: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub e Memória Compartilhada.

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

Execute-o no seu próprio hardware — os resultados serão diferentes dos números apresentados neste artigo, dependendo da sua CPU, sistema operacional, versão do kernel e ajustes. Esse é justamente o objetivo.

Conclusão

Não existe uma tecnologia de comunicação "perfeita". Cada nível tem requisitos únicos: externo (compatibilidade), interno (latência), pipeline (confiabilidade) e cliente (flexibilidade). Arquitetura é sobre escolher a ferramenta certa para a tarefa específica.