Empresas de desenvolvimento em Rust para plataformas de trading e matching engines: quais partes precisam de Rust e como contratar um time dedicado

Procure uma empresa cujos próprios engenheiros já construíram em Rust um matching engine ou outra parte do caminho da ordem e o mantêm rodando em produção. Antes de assinar, conheça as pessoas que entrariam no seu time. O Rust se paga onde um atraso custa dinheiro: no matching engine, nas checagens de risco pré-negociação, nos gateways para as bolsas e no handler de dados de mercado. Telas, relatórios e ferramentas de back-office podem continuar nas linguagens que a sua empresa já usa.

Quais empresas são especializadas em plataformas de trading e matching engines em Rust?

Este artigo não faz ranking de empresas. Uma especialista é uma empresa cujos próprios engenheiros já entregaram um sistema de trading em Rust e o operam para um cliente. Uma empresa que contrataria os seus engenheiros de Rust depois que você assinar está oferecendo, na verdade, um plano de contratação.

Código de trading costuma ser privado: em geral o cliente é dono dele e o mantém assim, então uma empresa forte pode ter pouco código de trading no GitHub. Em vez disso, peça a descrição completa de um sistema em produção: o que ele faz, quais partes são escritas em Rust, como a velocidade dele é medida, quem o opera hoje e o que quebrou depois do lançamento. Se um acordo de confidencialidade esconde o nome do cliente, peça à empresa que organize uma chamada com esse cliente.

Depois verifique as pessoas. Peça os nomes e a experiência em Rust dos engenheiros que trabalhariam no seu sistema e converse com eles antes de assinar. O artigo sobre times dedicados, com link acima, cobre as checagens gerais: código público, um teste pago e uma revisão por um engenheiro independente.

Quais partes de uma plataforma de trading devem ser escritas em Rust?

As que ficam no caminho de uma ordem, onde uma pausa de alguns milissegundos pode mudar o preço que o cliente recebe:

• O matching engine, que casa ordens de compra e de venda por preço e momento de chegada
• As checagens de risco pré-negociação, que barram uma ordem que viola um limite antes que ela chegue ao mercado
• Os gateways que enviam ordens às bolsas ou às corretoras e recebem as respostas delas
• O handler de dados de mercado, que lê os feeds de preços e repassa cada atualização

O Rust combina com essas partes porque libera memória sem garbage collector. Algumas linguagens usam um para essa tarefa, e ele pode pausar o programa no momento que ele mesmo escolher. O livro do Rust (o guia oficial da linguagem, consultado em 27 de outubro de 2026) diz que o ownership, o conjunto de regras por trás disso, “permite que o Rust dê garantias de segurança de memória sem precisar de um garbage collector”.

A linguagem, sozinha, não deixa um sistema rápido. Um programa em Rust ainda pode parar para pedir memória, esperar por um lock que outra thread está segurando ou esperar pela rede. O artigo sobre o design de um matching engine explica como um time tira tudo isso do caminho da ordem.

O resto da plataforma não tem prazo medido em milissegundos: telas web e mobile, contas de clientes, relatórios, back-office e ferramentas de administração. Essas partes podem continuar nas linguagens que os seus desenvolvedores ou fornecedores já usam. Uma empresa que propõe reescrevê-las em Rust deve explicar o que você ganha com isso.

Já temos uma plataforma rodando em C++, Java ou Go. Devemos reescrevê-la em Rust?

Em geral, não de uma vez. Um caminho mais seguro é mover um componente com uma fronteira clara, como as checagens de risco ou o handler de dados de mercado, e deixar o resto como está.

O novo componente pode rodar como um serviço separado que troca mensagens com o resto do sistema. Também pode ser construído como uma biblioteca que o código em C ou C++ chama diretamente. O Rustonomicon, o guia do projeto Rust sobre código unsafe e de baixo nível, explica como fazer isso numa seção chamada “Calling Rust code from C”.

Antes da troca, rode o novo componente ao lado do antigo com o mesmo fluxo de ordens gravado e compare cada resultado. Um matching engine determinístico sempre dá o mesmo resultado para as mesmas ordens na mesma sequência. Isso torna a comparação simples: se os dois motores aplicam as mesmas regras, qualquer diferença aponta para um bug em um deles.

Depois passe um mercado ou um grupo de instrumentos de cada vez e mantenha o componente antigo pronto para receber o tráfego de volta.

O que inclui um time dedicado terceirizado de Rust para um matching engine?

Um time dedicado trabalha só no seu sistema por meses ou anos, e os membros dele só mudam quando você concorda. Para um matching engine ou outra parte do caminho da ordem, ele costuma incluir:

• Engenheiros de Rust que já colocaram código em produção e sabem como uma ordem vive: tipos de ordem, execuções parciais, alterações e cancelamentos
• Um engenheiro líder que responde pelo design e revisa cada mudança no caminho da ordem
• Um engenheiro de testes que monta o ambiente que reproduz o fluxo de ordens gravado e confere os resultados
• Alguém responsável pelos servidores, pelas configurações de rede e pelos releases

A sua empresa também tem um papel nisso. Alguém do seu lado define as regras de negociação, como tamanho do tick, horário de negociação, taxas e o que acontece quando a negociação é interrompida, e responde às perguntas do time sobre elas sem longas demoras.

Freelancers podem ser engenheiros excelentes, mas com eles a continuidade é mais difícil. Um prestador sozinho não tem ninguém para revisar as mudanças no caminho da ordem, e quando essa pessoa sai, o que ela sabia sobre o seu sistema sai junto. Uma empresa pode substituir alguém e manter o conhecimento no time, e o contrato pode exigir isso dela.

Uma empresa só consegue dimensionar o time depois de ver as suas regras de negociação, os seus mercados e os seus volumes, então pergunte como ela chegou ao número que propõe.

O que devemos perguntar a um time de Rust sobre um matching engine?

O artigo sobre empresas de baixa latência mostra como verificar números de velocidade. Estas perguntas são sobre Rust e sobre o caminho da ordem:

• Onde o código de vocês usa unsafe e quem revisa essas partes?
• Como vocês testam o motor além de reproduzir ordens gravadas?
• De quais crates o caminho da ordem depende e como vocês os verificam em busca de vulnerabilidades conhecidas?
• Com qual versão do Rust vocês compilam e como decidem quando atualizar?
• Quem no time proposto já colocou Rust em produção, em qual sistema, e ele continua rodando?

O Rust verifica como a memória é usada quando o código é compilado. Dentro de um bloco marcado como unsafe, o código pode fazer cinco coisas que o compilador, de outra forma, recusa, como seguir um ponteiro bruto até a memória. O livro do Rust acrescenta que unsafe “não desliga o borrow checker nem desativa nenhuma das outras verificações de segurança do Rust”. Uma boa resposta diz onde fica o código unsafe, por que ele é necessário ali e quem o revisou.

Quanto aos testes, um time deve citar as ferramentas que usa. O cargo-fuzz, que o Rust Fuzz Book chama de “a ferramenta recomendada para fuzz testing de código Rust”, alimenta um programa com grandes volumes de entradas geradas para encontrar os casos que o derrubam. O Loom, uma biblioteca para testar código que roda em várias threads, “roda os testes muitas vezes, permutando as possíveis execuções concorrentes de cada teste”. Isso encontra bugs que só aparecem quando as threads, por azar, rodam numa ordem ruim.

Crates são os pacotes de código compartilhado do Rust. O RustSec Advisory Database registra alertas de segurança sobre crates publicados no crates.io. A ferramenta dele, o cargo-audit, verifica o Cargo.lock de um projeto, o arquivo que lista a versão exata de cada dependência, “em busca de crates com vulnerabilidades de segurança”. Um time que trabalha num caminho de ordens deve saber dizer se essa verificação roda em cada build.

O Rust lança uma nova versão estável a cada seis semanas, e o livro do Rust diz que “você nunca deveria ter medo de atualizar para uma nova versão estável do Rust”. Mesmo assim, um time pode manter todos os builds numa versão escolhida. A documentação do rustup, o instalador do Rust, descreve um arquivo de toolchain para projetos que se veem “‘fixados’ numa versão específica do Rust” e querem registrar isso no repositório. Num caminho de ordens, a versão só deve mudar de propósito, depois que os testes passarem.

O que o contrato com um time de Rust deve dizer?

Coloque nele estes pontos:

• O código, os testes, os dados de replay e os scripts de build ficam em repositórios que pertencem à sua empresa
• Builds e releases rodam em contas abertas em nome da sua empresa
• Quem pode mudar o caminho da ordem e quem revisa cada mudança
• As horas que o time cobre e quem responde se o motor falhar fora delas
• O que você recebe se o contrato terminar: documentação, acessos e tempo do time para fazer a passagem ao próximo

Onde a amBrain se encaixa?

A amBrain, que publica este blog, se descreve em uma linha: “A amBrain é uma empresa de engenharia de software de Yerevan, Armênia, que constrói plataformas de trading de baixa latência, matching engines e sistemas de real-time bidding em Rust.” Outra linha diz: “A amBrain constrói infraestrutura de trading algorítmico: execução de ordens, dados de mercado e controles de risco pré-negociação.”

A amBrain constrói software desde 2019. O time dela, nas palavras dela: “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. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.”

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes. Ele não diz quais sistemas a amBrain construiu em Rust nem para quem, e não traz preços, prazos nem tamanhos de time da amBrain. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.