Empresas de desenvolvimento de software de baixa latência: de qual tipo você precisa e como testar uma no seu próprio sistema

Nenhuma lista de empresas de desenvolvimento de software de baixa latência serve para todo comprador, porque o termo cobre deadlines que podem diferir um milhão de vezes entre si. Em hardware de trading, pode significar dezenas ou centenas de nanossegundos. Em um app ou em uma página web, uma resposta em cerca de um décimo de segundo já parece instantânea para quem a usa. Então a primeira pergunta é onde fica o seu próprio deadline.

O que “baixa latência” significa para o nosso sistema?

Para o seu sistema, baixa latência é um deadline medido entre dois pontos que você consegue nomear. Os deadlines se dividem em quatro grandes faixas:

• Hardware de trading, em dezenas ou centenas de nanossegundos. O STAC-T0, um benchmark desenvolvido em consulta com empresas de trading do STAC Benchmark Council, mede a rapidez com que o hardware e o software de rede de um sistema transformam dados de mercado simulados em uma ordem simulada, sem nenhuma lógica de trading no meio. A visão geral do STAC de 5 de novembro de 2020 diz que o benchmark trata o sistema como uma caixa-preta, “interagindo com ele apenas por meio de pacotes de rede, aos quais atribui timestamps em hardware”, e que timestamps de software podem trazer um erro considerável na escala de dezenas ou centenas de nanossegundos. A stack sob teste (stack under test), como o STAC chama o sistema que está sendo medido, pode ser uma placa FPGA, que traz um chip cujos circuitos são programados para uma única tarefa
• Locais de negociação, de microssegundos até cerca de um milissegundo. A regra da UE sobre a precisão que os relógios de um local de negociação devem ter vincula essa precisão ao tempo que o sistema de negociação do local leva para processar uma ordem e devolver uma confirmação. Desde 2 de março de 2026, essa regra é o Regulamento Delegado (UE) 2025/1155 da Comissão, que substituiu a regra anterior conhecida como RTS 25 e chama esse tempo de latência gateway a gateway (gateway-to-gateway latency), “o tempo medido a partir do momento em que uma mensagem é recebida por um gateway externo do sistema do local de negociação, enviada pelo protocolo de envio de ordens, processada pelo matching engine e depois enviada de volta até que uma confirmação seja enviada pelo gateway”. Quando isso leva 1 milissegundo ou menos, os relógios do local de negociação podem se desviar no máximo 100 microssegundos do Tempo Universal Coordenado (UTC), e os timestamps precisam ter granularidade de 0,1 microssegundo ou mais fina
• Ad tech, de dezenas de milissegundos até um segundo. O OpenRTB 2.6, o padrão do IAB Tech Lab para real-time bidding, permite que uma exchange defina um deadline em cada bid request, e o tempo gasto atravessando a Internet conta dentro dele. A documentação para desenvolvedores do Authorized Buyers do Google, atualizada pela última vez em 17 de setembro de 2026, diz que o deadline de resposta “vai de 80 a 1000 ms, dependendo do formato e do tipo de leilão”
• Apps e páginas web que as pessoas usam, em torno de um décimo de segundo. Jakob Nielsen escreveu em 1993 que “0,1 segundo é mais ou menos o limite para que o usuário sinta que o sistema está reagindo instantaneamente”. Para páginas web, o guia do web.dev do Google, atualizado pela última vez em setembro de 2025, classifica a responsividade como boa quando o Interaction to Next Paint (INP) é de 200 milissegundos ou menos. O INP mede quanto tempo uma página leva para responder a cliques, toques e teclas pressionadas

Um mesmo produto pode ter partes em faixas diferentes. Um trader lê os preços em uma tela, enquanto a ordem que esse trader envia pode ter que cumprir um deadline bem mais apertado no caminho até o local de negociação. Escreva cada deadline com os dois pontos entre os quais ele é medido. A faixa em que cada um cai diz qual tipo de empresa chamar.

Com quais empresas de desenvolvimento de software de baixa latência devemos conversar?

Este artigo não faz ranking de empresas. O tipo certo de empresa depende da sua faixa e do trabalho que você precisa que seja feito:

• Especialistas em hardware e redes, para deadlines contados em nanossegundos ou em poucos microssegundos. Eles trabalham com placas FPGA, placas de rede, switches e os links até uma bolsa. Pergunte quais dos números deles vêm de timestamps registrados por hardware no cabo de rede, e em equipamento de quem os testes rodaram
• Empresas de engenharia de tecnologia de trading, para deadlines em microssegundos ou milissegundos quando o tempo se perde dentro do seu próprio software ou no caminho até a sua corretora ou o local de negociação. Elas escrevem o software que envia ordens, processa dados de mercado, verifica o risco de cada ordem antes de ela sair e, em um local de negociação, casa ordens de compra e venda. Pergunte quais sistemas construídos por elas estão em produção hoje e quais conexões com corretoras ou locais de negociação elas escreveram
• Empresas de engenharia de ad tech, quando uma exchange define o seu deadline requisição por requisição e a sua conta de servidores cresce com o seu tráfego. Elas constroem bidders e ad exchanges. Pergunte qual bidder ou exchange construído por elas continua em produção, e se os números de timeout dele vêm da contagem da exchange ou da contagem delas
• Engenheiros de performance independentes, quando você ainda não sabe a causa ou quando os seus próprios engenheiros vão fazer as mudanças. Geralmente trabalhando sozinhos ou em um grupo pequeno, eles medem um sistema em funcionamento e relatam para onde vai o tempo. Peça para ver um relatório anterior, com o nome e os dados do cliente removidos, e espere um diagnóstico, não uma reconstrução
• Fornecedores de componentes, quando a peça de que você precisa funciona do mesmo jeito para todo mundo e a sua vantagem está em outro lugar. Eles vendem uma peça pronta, como um matching engine ou uma conexão com bolsa, que você opera em vez de encomendar a sua própria. Pergunte de onde até onde os números de latência deles foram medidos, e o que você pode alterar no código que licencia
• Empresas generalistas de outsourcing com um time de baixa latência identificado, quando você precisa de muitos engenheiros e o caminho crítico de latência é uma parte pequena do trabalho. Peça os nomes das pessoas desse time e o que cada uma delas construiu na sua faixa, e obtenha por escrito o compromisso de que elas vão trabalhar no seu projeto
• Contratações próprias, quando a velocidade é a sua forma de competir e vai continuar sendo, e você consegue recrutar e reter engenheiros que já colocaram esse tipo de sistema em produção. A Acuiti, uma empresa de pesquisa, perguntou a 50 hedge funds sistemáticos, fundos que operam com base em modelos computacionais, como eles constroem a tecnologia de trading. Em janeiro de 2023, ela relatou que a latência “é o fator-chave na definição das atitudes em relação à terceirização da tecnologia de front office, e as empresas para as quais a latência é crítica têm mais probabilidade de desenvolver internamente”

Muitas empresas se encaixam em mais de um tipo, então pergunte que tipo de trabalho os engenheiros alocados para você já fizeram.

Como verificar se uma empresa já construiu sistemas rápidos antes?

O artigo sobre times dedicados, com link acima, lista o que deve acompanhar cada número de performance e traz um checklist que você pode colar em uma solicitação de proposta (RFP). As perguntas abaixo descobrem como os números da própria empresa foram produzidos.

Pergunte onde o relógio começa e onde ele para. A OPRA, que publica os negócios e as cotações consolidados das bolsas de opções dos EUA, inicia o relógio quando uma mensagem de entrada “chega à entrada da aplicação no ambiente da OPRA” e o para quando a mensagem de saída “chega à saída da aplicação do ambiente da OPRA”. A definição da UE citada acima é igualmente precisa sobre os dois pontos. Um número sem pontos de início e fim definidos não pode ser comparado com o seu.

Olhe as respostas mais lentas, além da típica. Nas métricas publicadas pela OPRA, a latência mediana, o valor do meio, foi de 19,5 microssegundos em janeiro de 2024 e de 20,5 em fevereiro. Nos mesmos dois meses, o percentil 99, o tempo que só o 1 por cento mais lento das mensagens ultrapassou, caiu de 543,5 microssegundos para 57,5. Um relatório só com a mediana teria mostrado quase nenhuma mudança.

As médias também escondem as respostas lentas. O livro Site Reliability Engineering, do Google, publicado pela O'Reilly em 2016, descreve um serviço web com latência média de 100 milissegundos a 1.000 requisições por segundo, em que “1% das requisições pode facilmente levar 5 segundos”. Peça o percentil 99 de cada caminho e, se o seu sistema processa requisições suficientes para medi-lo, o percentil 99,9, que só 1 resposta em 1.000 ultrapassa.

Verifique a carga por trás de cada número. Na visão geral do STAC de 2020, o STAC-T0 envia o tráfego de teste em três taxas. A mais baixa é “pensada para ver como os sistemas se comportam quando estão quase ociosos”, e a mais alta, normalmente perto do máximo que o sistema testado aguenta, existe “para ver como os sistemas se comportam quando estão muito ocupados”. Peça números do seu próprio minuto mais movimentado, ou de um teste que o reproduza.

Pergunte como o teste de carga foi feito. Muitas ferramentas de teste de carga enviam uma requisição, esperam a resposta e só então enviam a próxima. Quando o sistema trava, uma ferramenta assim para de enviar, então as requisições que teriam chegado durante a paralisação nunca são medidas.

Gil Tene, autor da ferramenta de teste de carga wrk2, chama esse efeito de coordinated omission. Na documentação da ferramenta, alterada pela última vez em setembro de 2019, ele escreve que “respostas de alta latência fazem com que o gerador de carga se coordene com o servidor para evitar medições durante os períodos de alta latência”. A ferramenta dele envia requisições a uma taxa fixa e mede cada resposta “a partir do momento em que a transmissão deveria ter ocorrido”. Pergunte se a ferramenta da empresa funciona assim, ou como os resultados dela foram corrigidos.

Pergunte onde cada timestamp foi registrado. Para latências em microssegundos, a visão geral do STAC chama um benchmark com timestamps de software de “a melhor opção”. Ela também alerta que os pequenos atrasos irregulares dos timestamps de software “podem representar um erro considerável ao medir latências de dezenas ou centenas de nanossegundos”, e o STAC-T0, em vez disso, registra os timestamps em hardware. Uma empresa que cita nanossegundos deve conseguir mostrar onde os timestamps de hardware dela foram registrados.

Que teste devemos fazer antes de contratar alguém?

Se você ainda não sabe o que está errado, só que o sistema parece mais lento ou custa mais do que deveria, comece por aqui. Pague a empresa da sua preferência por uma medição de escopo fechado do seu sistema em produção, com um relatório que continua seu, seja qual for a sua decisão seguinte. Combine por escrito o que a empresa pode instalar ou alterar para fazer as medições, e como as ferramentas dela são removidas depois.

O relatório deve mostrar:

• Para onde vai o tempo no seu minuto mais movimentado, etapa por etapa ao longo do caminho que você escreveu
• Para cada caminho, os tempos de resposta nos percentis 99 e 99,9
• As correções, ordenadas pelo que cada uma custa e pelo que elimina, seja tempo no caminho, sejam servidores que foram adicionados para esconder um caminho lento
• Em que a empresa não mexeria, e por quê

Para sistemas de trading, o artigo sobre execução lenta de ordens, com link acima, lista os quatro timestamps a registrar em cada ordem. Em ad tech, os artigos sobre picos de tráfego e sobre timeouts de DSP tratam do que medir em um pico e em cada conexão de exchange.

Avalie a empresa pelo relatório. Se os seus próprios engenheiros conseguiriam agir com base nele sem a empresa, você pode escolher quem faz o trabalho seguinte a partir de números reais, seja essa empresa ou outra.

Quais são os sinais de alerta ao escolher uma empresa de baixa latência?

• Velocidade descrita em palavras, sem número e sem pontos de início e fim
• Só médias, sem nada sobre as respostas mais lentas
• Um benchmark do laboratório da própria empresa, rodado no hardware dela com tráfego gerado por ela, apresentado como evidência sobre o seu sistema
• Uma reescrita, ou a migração para uma nova linguagem de programação, proposta antes que alguém tenha medido o seu sistema
• Um número de latência prometido já na primeira chamada
• O mesmo discurso de vendas para trabalho de trading medido em microssegundos e para um bidder de anúncios com deadline de 100 milissegundos

Se uma empresa propõe uma nova linguagem, o artigo com link abaixo mostra como os engenheiros verificam se a linguagem é a causa.

Onde a amBrain se encaixa?

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. O trabalho dela em trading inclui desenvolvimento de terminais de trading, sistemas de gestão de ordens e integração com bolsas via protocolo FIX.

Em AdTech, a amBrain trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange.

A amBrain 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.

A amBrain constrói software desde 2019.

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.

Pergunte à amBrain, ou a qualquer outra empresa da sua lista, o que ela mediria primeiro no seu sistema, e submeta todas as empresas às mesmas verificações.

Perguntas comuns

• Devemos montar um time próprio em vez disso? No estudo da Acuiti de 2023 com 50 hedge funds sistemáticos, aqueles para os quais a latência é crítica tinham mais probabilidade de desenvolver internamente a tecnologia de trading. Meça primeiro em qualquer caso, porque o relatório diz que tipo de engenheiro contratar, ou o que pedir a uma empresa
• Uma única empresa consegue cobrir trading e ad tech? Consegue, se tiver sistemas em produção na sua faixa nas duas áreas. Peça um sistema em produção em cada área e verifique os números dele com as perguntas acima