FIX vs REST vs WebSocket no fluxo de ordens de brokers

Em quase toda configuração, o caminho das ordens é misto

Em quase toda configuração de broker ou prop firm, o fluxo de ordens passa por pelo menos duas interfaces antes de chegar a um mercado. Um aplicativo do cliente pode enviar ordens por REST, receber atualizações por WebSocket e, em seguida, encaminhar ordens a um provedor de liquidez ou bolsa por FIX.

Raramente a decisão é usar um único protocolo para tudo. A questão é qual interface fica responsável por cada ação e como o sistema se comporta quando uma confirmação ou atualização não chega.

Comece pelo ciclo de vida da ordem, e não por uma preferência de protocolo. Mapeie envio, confirmação, substituição, cancelamento, rejeição, execução parcial, execução e correção.

Para cada transição, registre o sistema de registro, o identificador da mensagem e a rota de recuperação. Isso revela lacunas, como um timeout de REST depois que o servidor aceitou uma ordem ou uma desconexão do WebSocket durante uma execução parcial.

Equipes que comparam projetos de plataforma podem usar a cobertura de infraestrutura da Trading Technology como contexto, mas a decisão deve se basear no comportamento medido na rota real.

Trate as interfaces como contratos diferentes

FIX é um protocolo de sessão com tipos de mensagem definidos, números de sequência, heartbeats e mecanismos de recuperação. É adequado ao fluxo de ordens persistente e com estado entre empresas e mercados.

As implementações ainda variam conforme a contraparte, a versão do FIX e os campos compatíveis. Certificação, configuração de sessão e tratamento cuidadoso das redefinições de sequência fazem parte do trabalho, não são detalhes opcionais.

REST é um modelo de solicitação e resposta sobre HTTP. É simples de integrar, inspecionar e operar, e se encaixa em operações de conta, entrada de ordens em volumes moderados e ações administrativas.

O caso difícil é um resultado ambíguo: o cliente sofre um timeout, mas o servidor pode ter aceitado a ordem. Repetir um POST sem um ID estável de ordem do cliente e um comportamento de idempotência documentado pode criar uma duplicata.

WebSocket é um transporte persistente, não um padrão de mensagens de trading. Os provedores costumam usá-lo para enviar eventos de ordens e execuções, dados de mercado ou atualizações de conta.

Alguns também aceitam comandos por essa interface. Reconectar, por si só, não recupera eventos perdidos, então a API precisa oferecer números de sequência, replay, um novo snapshot ou outra forma de reconciliação.

• Para FIX, teste logon, perda de heartbeat, solicitações de reenvio, relatórios de execução duplicados e failover entre sessões.
• Para REST, teste limites de taxa, comportamento em caso de timeout, idempotência, paginação e se é possível consultar uma ordem pelo ID do cliente.
• Para WebSocket, teste o tratamento de heartbeat, lacunas de sequência, intervalo progressivo entre tentativas de reconexão e consistência entre snapshot e stream.

Nas três interfaces, mantenha um ID interno de ordem durável e associe-o aos identificadores do cliente, do broker e do mercado. A cobertura de infraestrutura de brokers da Trading Technology aborda o contexto mais amplo das plataformas; ainda assim, o contrato de integração precisa ser verificado conforme a especificação de cada provedor.

Calcule o custo da integração e, depois, o custo da falha

A escolha do protocolo afeta o esforço de engenharia, a certificação e o suporte contínuo. Os valores abaixo são faixas típicas de mercado para uma integração entre um broker e um provedor. As cobranças diretas variam conforme o fornecedor e o modelo de conectividade; essas faixas não incluem salários, taxas de trading do mercado nem colocation.

Essas são faixas para planejamento, não propostas comerciais. Um provedor pode incluir o acesso por WebSocket no REST, cobrar à parte pelos dados de mercado ou exigir uma linha FIX paga e certificação. Peça a tabela completa de tarifas e as condições do ambiente de testes antes de comparar propostas.

A latência também exige um ponto de medição definido. Registre separadamente o horário de envio pelo cliente, o recebimento pelo gateway, a confirmação do mercado e o evento de execução. Rotas pela internet pública costumam ter tempos de ida e volta de dezenas de milissegundos, enquanto uma rota em colocation bem configurada pode ficar na faixa baixa de um dígito de milissegundos ou abaixo. Essas são faixas típicas de mercado, não um compromisso de serviço. Provedor, localização geográfica, rota de rede e carga do mecanismo de negociação são fatores relevantes.

Projete a recuperação em torno do estado da ordem

Um socket ativo não prova que o livro de ordens do seu aplicativo está correto. Mantenha uma máquina de estados que processe confirmações e relatórios de execução, elimine eventos duplicados e reconcilie ordens em aberto e execuções com uma fonte oficial. No FIX, MsgSeqNum e o tratamento de reenvios restauram mensagens da sessão, mas, por si só, não provam que o aplicativo processou corretamente todos os eventos de negócio.

Escolha e documente o comportamento esperado para quatro casos ambíguos: timeout no envio, timeout no cancelamento, desconexão do stream após uma execução parcial e reinício do processo com ordens ainda em aberto. Em cada caso, identifique se o sistema consulta pelo ID da ordem do cliente, solicita um snapshot de ordens em aberto, reproduz eventos ou encaminha o caso a um operador. Não reenvie uma ordem simplesmente porque o timer local de confirmação expirou.

Defina limites com base nas distribuições observadas em produção. Acompanhe a latência de confirmação p50, p95 e p99, a taxa de rejeição, o atraso dos eventos, o número de reconexões, as lacunas de sequência e as diferenças de reconciliação. Um bom primeiro objetivo é gerar um alerta para qualquer ordem não reconciliada, não apenas quando um percentil de latência estiver elevado. Mantenha as mensagens brutas do protocolo por tempo suficiente para esclarecer disputas e reproduzir um defeito em um ambiente controlado.

Siga este checklist ao longo de cinco dias úteis

Limite o escopo a uma rota representativa e a um tipo de conta. O objetivo desta semana é reunir evidências que embasem uma escolha, não fazer uma reformulação ampla.

1. Dia um: mapeie o ciclo de vida. Desenhe cada transição da ordem, do envio pelo cliente ao relatório final de execução. Marque onde os identificadores são criados, transformados e persistidos.
2. Dia um: leia o contrato do provedor. Confirme os tipos de ordem aceitos, os limites de taxa, as regras de idempotência, as redefinições de sessão, o replay de eventos e as diferenças do ambiente de testes. Registre as perguntas ainda sem resposta para o provedor.
3. Dia dois: instrumente os timestamps. Registre os horários de envio, recebimento pelo gateway, confirmação e evento de execução usando relógios sincronizados. Verifique a diferença entre os relógios e armazene medições de relógio civil e monotônico.
4. Dia dois: estabeleça uma linha de base. Execute volumes de ordens representativos e registre latência p50, p95 e p99, rejeições, limitação de taxa, atraso dos eventos e reconexões. Separe o tempo de rede do processamento do aplicativo.
5. Dia três: injete falhas. Interrompa uma conexão após o envio, atrase uma resposta, reinicie um consumidor e provoque uma lacuna de sequência quando o ambiente de testes permitir. Verifique se cada caso resulta em um único estado correto da ordem.
6. Dia quatro: teste a reconciliação. Compare as ordens em aberto e as execuções internas com o snapshot ou os resultados de consulta do provedor. Inclua execuções parciais, disputas entre cancelamento e substituição, eventos duplicados e relatórios atrasados.
7. Dia quatro: calcule o custo operacional total. Some suporte de engenharia, certificação, conectividade, monitoramento e carga de plantão às cobranças diretas do fornecedor. Registre quais custos mudam com o volume de ordens ou com a adição de mercados.
8. Dia cinco: decida a rota. Escolha a interface conforme a ação e o comportamento diante de falhas; depois, documente os objetivos de latência, as etapas de recuperação, a responsabilidade pelo escalonamento e as evidências que levariam a uma revisão.

Escolha por rota, não por modismo

REST pode ser uma boa escolha para entrada de ordens quando as taxas de solicitação são moderadas, há idempotência documentada e a plataforma consegue reconciliar resultados incertos. WebSocket costuma ser adequado para atualizações em tempo real, desde que o stream permita detectar lacunas e se recuperar delas com confiabilidade. FIX geralmente se justifica quando as contrapartes o exigem, quando as taxas de ordens ou os controles de sessão demandam esse protocolo ou quando o modelo operacional depende de conectividade institucional persistente.

Projetos híbridos são comuns. Um broker pode usar REST para operações de conta, WebSocket para atualizações voltadas ao cliente e FIX para execução no mercado. Mantenha os limites explícitos: um componente deve ser responsável pelo estado da ordem, as tentativas devem ser deliberadas e cada evento precisa ser rastreável entre os identificadores.

Se esta fosse a minha operação, eu começaria rastreando uma ordem real desde o envio pelo cliente, passando pela confirmação, execução e reconciliação, e depois injetaria um timeout em cada etapa. Só escolheria a interface depois que esse teste mostrasse como o sistema comprova se uma ordem existe.

#infraestrutura de broker #API REST de trading #API WebSocket de trading #recuperação de sessão FIX #protocolo FIX #fluxo de ordens de broker #integração da execução de ordens #latência da API de trading