O livro de ofertas trava quando o mercado fica movimentado? Como corrigir o feed de dados de mercado e quem pode fazer isso

Se o livro de ofertas nas suas telas de trading trava, dá saltos ou mostra preços impossíveis quando o mercado está movimentado, a falha costuma estar em um de três lugares. As atualizações se perdem onde o feed da bolsa entra, o livro é montado errado ou chega devagar demais a centenas de telas. Meça o seu horário de pico antes de contratar alguém e depois teste cada empresa que você considerar com uma gravação desse dia.

Como um feed de dados de mercado com defeito aparece na tela?

Isso aparece nos momentos de maior movimento, como um anúncio de banco central ou a abertura do mercado. O livro na tela para por um ou dois segundos e depois dá um salto. Ordens canceladas continuam visíveis. Às vezes, o preço mais alto que um comprador oferece fica acima do preço mais baixo que um vendedor pede, o que se chama de livro cruzado. Em uma única bolsa, fora dos leilões de abertura e de fechamento, essas ordens seriam casadas na hora. Por isso, um livro cruzado de uma única bolsa na sua tela significa que a sua cópia desse livro está errada.

Aí o suporte recebe capturas de tela de dois traders que veem livros diferentes para o mesmo instrumento. Ou um trader contesta o preço pelo qual uma ordem foi executada, porque a tela mostrava outro.

Por que as atualizações se perdem ou chegam fora de ordem?

O feed do livro de ofertas de uma bolsa é um fluxo de pequenas mudanças: uma ordem incluída, uma ordem cancelada, um negócio. O seu sistema parte de uma cópia completa do livro, chamada snapshot, e aplica as mudanças em ordem. Cada mudança é numerada, então dá para perceber quando falta uma. A especificação da Nasdaq para o feed TotalView-ITCH 5.0 diz que o feed “é composto por uma série de mensagens sequenciadas”, ou seja, numeradas em ordem.

Em um mercado movimentado, o fluxo de mudanças sobe bruscamente. Algumas se perdem no caminho ou dentro dos seus próprios servidores, e algumas chegam fora de ordem. Se o sistema não percebe a lacuna, aplica o que chegar e mostra um livro que já não corresponde ao da bolsa. Se percebe a lacuna, mas leva segundos para se recuperar, a tela fica parada.

As bolsas partem do princípio de que os clientes vão perder atualizações. A documentação do CME Group para o feed MDP 3.0 diz que, depois de uma lacuna, “deve-se presumir que todos os livros mantidos no sistema do cliente podem não ter mais o estado correto e mais recente”.

Em que ponto do sistema o feed quebra?

São três lugares, e cada um precisa da sua própria correção. Os engenheiros chamam o terceiro de fan-out, porque um único fluxo de atualizações se abre em leque para muitas telas. O artigo técnico com link acima trata dos três em detalhes.

O primeiro lugar é a entrada, onde chega o feed da bolsa. Algumas bolsas oferecem formas de recuperar dados perdidos. Um dos protocolos de entrega da Nasdaq, o MoldUDP64, permite que os receptores “detectem e solicitem novamente os pacotes perdidos”. A CME envia o seu fluxo duas vezes, em linhas chamadas A e B, e mantém um feed separado de snapshots para atualizar os livros. Nada disso ajuda se o seu sistema não percebe a lacuna.

Depois o livro é montado, e aqui o perigo é uma mudança aplicada duas vezes, fora de ordem ou em cima do snapshot errado. A Binance, uma exchange de cripto, descreve no seu guia os passos exatos para unir um snapshot ao fluxo ao vivo. Um livro montado sem eles continua mostrando preços e parece normal, mas os preços estão errados.

Por último vem o fan-out, em que o livro sai para centenas de sessões de traders, uma para cada tela conectada. Um trader com uma conexão móvel fraca, ou um terminal que travou, lê as atualizações devagar. Se o servidor espera por essa sessão, todas as outras sessões esperam também. Deixar a fila de atualizações pendentes dessa sessão crescer sem limite não é melhor, porque o servidor fica sem memória e cai para todo mundo.

Em um sistema bem construído, o servidor coloca as atualizações em ordem uma única vez e envia o mesmo resultado a todas as sessões. Uma sessão que fica para trás ou recebe o retrato mais recente do livro e pula os passos intermediários, ou é desconectada pelo servidor com o motivo informado, e a tela se reconecta com uma cópia nova. Um feed pode quebrar em mais de um lugar ao mesmo tempo.

O que medir antes de contratar alguém?

Pegue o horário de pico do último mês e levante estes números para ele:

• Lacunas: quantas vezes o sistema encontrou um número de atualização faltando em cada feed de bolsa. Se o sistema não as conta, essa é a sua primeira constatação
• Tempo de recuperação: quanto tempo levou cada reconstrução e o que os traders viram nesse meio-tempo
• Atraso: o tempo entre o timestamp da bolsa em uma mensagem e o momento em que a atualização sai do seu servidor para o trader e, em alguns terminais de teste, até a tela. Pegue a mediana e o percentil 99, o tempo abaixo do qual ficam 99 de cada 100 atualizações. Mantenha os relógios dos seus servidores sincronizados com uma fonte de horário precisa, ou os números não vão significar nada
• Sessões: quantas ficaram para trás, por quanto, e quantas foram desconectadas, com o motivo de cada desconexão

Depois grave o feed bruto de um dia movimentado exatamente como ele chegou, com o horário de chegada de cada pacote. Reproduzir essa gravação em velocidade real e mais rápido é o teste que você aplica a cada empresa da sua lista e repete depois de cada correção.

Corrigir o nosso handler, comprar um ou reconstruir o fan-out?

O software que recebe o feed de uma bolsa e mantém o livro se chama feed handler. Você tem três caminhos, e as suas medições devem apontar para um deles. Os dois últimos podem ser combinados.

Quando faz sentido corrigir o nosso próprio feed handler?

Corrija o feed handler que você já tem quando as medições apontam para uma falha clara, como lacunas que passam despercebidas ou uma reconstrução lenta, e as pessoas que conhecem o código ainda estão por perto.

• Quando faz sentido: uma falha que você consegue apontar e um design que, fora isso, funciona
• O que você paga: tempo de engenharia e uma bancada de testes que reproduz as suas gravações
• Quem é o dono do código: você
• O limite: uma correção na entrada não ajuda se o problema está no envio do livro para as telas

Quando devemos comprar um feed handler ou um feed gerenciado?

Um feed handler pronto é um software licenciado que se conecta a uma bolsa, detecta as lacunas e entrega ao seu sistema um livro de ofertas correto e atualizado. Um feed gerenciado vai além: um fornecedor de dados de mercado se conecta às bolsas, e você recebe dele um único fluxo em um único formato.

• Quando faz sentido: muitas bolsas em formatos padrão, e nenhuma vontade de acompanhar cada mudança que cada bolsa faz no próprio feed
• O que você paga: a licença e o trabalho de conectar o produto ao seu sistema. As taxas de dados e os termos de licença das próprias bolsas normalmente continuam valendo, seja quem for que entregue os dados
• O que continua com você: levar o livro a centenas de telas de traders e lidar com sessões lentas
• Quem é o dono do código: o fornecedor é dono do produto. Você é dono da integração e de tudo o que vem depois dela

Quando devemos contratar um time para reconstruir o fan-out?

Reconstrua a camada que envia os dados aos traders quando a entrada funciona, mas o problema continua. Os traders ainda veem livros diferentes, uma sessão lenta atrasa as demais, ou você planeja atender muito mais sessões do que hoje.

• Quando faz sentido: o atraso cresce entre os seus servidores e as telas, não entre a bolsa e os seus servidores
• O que você paga: tempo de engenharia e de testes e, depois, as pessoas que operam o sistema após o lançamento
• Quem é o dono do código: você, se o contrato disser isso

Como verificar uma empresa antes de contratá-la?

Submeta todas as empresas da sua lista aos mesmos cinco testes:

• Uma reprodução da sua gravação, em velocidade real e várias vezes mais rápida, passando pelo que a empresa entregar ou demonstrar. Compare as lacunas, as reconstruções, os tempos de recuperação e os atrasos com os do seu sistema atual
• Como o sistema detecta uma lacuna. Uma boa resposta diz que o sistema só aplica uma mudança quando o número dela é o próximo esperado. Se falta um número, o sistema espera um pouco e depois pede a mudança de novo ou reconstrói o livro. Até lá, ele marca o livro como desatualizado. Pergunte o que os traders veem nesse meio-tempo
• O que acontece com um único trader lento. Peça à empresa que deixe uma sessão lenta de propósito durante a reprodução. Os atrasos das outras sessões não devem mudar
• Como o atraso é medido: de qual timestamp até qual ponto, em qual percentil, com qual carga e qual hardware, e como os relógios são mantidos sincronizados
• Quem é o dono do código, e em que condições você usa as partes que a empresa mantém como próprias

Quais são os sinais de alerta?

• “Vamos acrescentar mais servidores” como primeira resposta, antes que alguém tenha visto as suas medições
• “Usamos uma conexão confiável, então nada se perde.” A Binance envia as suas atualizações por WebSocket, uma conexão que não perde dados no caminho, e mesmo assim o guia dela diz aos clientes o que fazer quando eventos são pulados

Onde a amBrain se encaixa?

A amBrain constrói infraestrutura de trading algorítmico: execução de ordens, dados de mercado e controles de risco pré-negociação.

Uma linha do site da amBrain diz: “Desenvolvimento de terminais de trading, sistemas de gestão de ordens e integração com bolsas via protocolo FIX.”

A amBrain diagnostica sistemas lentos em trading e ad tech: a plataforma em funcionamento é medida de ponta a ponta, e o relatório aponta para onde vai o tempo.

A amBrain constrói software desde 2019. Ela descreve o seu time em uma linha: “Um time de até 40 pessoas, cerca de 75% delas sêniores.” Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain.

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes. Ele não cita nenhum número de latência de qualquer sistema que a amBrain tenha construído, nem preços ou prazos.

Se a amBrain estiver na sua lista curta, faça a ela as mesmas cinco perguntas que a todas as outras empresas, e faça da sua gravação o critério de aprovação de qualquer trabalho que vocês combinarem.

Perguntas comuns

• Mais servidores resolvem? Sozinhos, não. Se o sistema aplica as mudanças fora de ordem ou espera pela sessão mais lenta, mais servidores repetem a mesma falha. Acrescente servidores quando as medições mostrarem que os atuais estão ficando sem capacidade
• Podemos juntar atualizações e enviar menos delas? Para o livro de ofertas, sim. Os engenheiros chamam isso de conflation, e algumas bolsas fazem isso elas mesmas. A documentação da Binance define a velocidade de atualização do seu fluxo spot de mudanças do livro de ofertas em 1000 ms ou 100 ms. Avise os traders de que o fluxo mostra o retrato mais recente, não cada passo. Não junte negócios nem confirmações de ordens, porque descartar um deles deixa o histórico de negociação errado
• Precisamos reescrever em Rust ou C++? Não necessariamente. Lacunas não detectadas e um servidor que espera pela sessão mais lenta são falhas de design que uma linguagem nova não elimina. Rust e C++ não têm garbage collector, a limpeza automática de memória que pode pausar um programa escrito em uma linguagem como Java ou Go. Isso ajuda nas partes do sistema que processam cada atualização. Seja qual for a linguagem, peça o atraso medido no pico
• Quanto tempo leva uma correção? Depende de onde está a falha e de quantas bolsas e sessões você tem. Peça a cada empresa um orçamento e um cronograma para uma primeira fase que inclua as medições e um ambiente de testes que reproduza a sua gravação. Use os cinco testes acima como critérios de aprovação