Pipeline em Rust: por que reescrevemos o motor da Luminary

Construir um pipeline em Rust não foi uma escolha óbvia em 2023. Quando começamos a construir a Luminary, a sabedoria convencional dizia: Node.js para a API, Python para ML, talvez Go para os workers. Esse é o stack SaaS moderno. Rejeitamos. Construímos o motor de pipelines em Rust. Não porque é moda — porque tudo mais que tentamos morreu em escala.

Os três predecessores que falharam antes do pipeline em Rust

V1 (Node): ótima DX, API bonita, começou a derreter aos 12 mil eventos/s. As pausas de garbage collection ficaram inaceitáveis nos 50 mil.

V2 (Go): melhores características de runtime. Bateu em uma parede aos 180 mil eventos/s quando o grafo de workflow ficou esparso. Contenção de mutex no scheduler.

V3 (Rust): hoje sustenta 1,2 milhão de eventos/s por nó. Ainda não achamos o teto.

O que faríamos diferente

Rust não é de graça. O impacto na produtividade do time nos primeiros seis meses foi real — onboarding levou mais tempo, e queimamos três semanas atrás de um problema de memory-mapping que não existiria no Node.

Se fôssemos começar de novo: escreveríamos a camada de API em Go (a ergonomia de Rust para HTTP ainda é dura em 2026), manteríamos o motor em Rust e moveríamos a inferência de ML para Mojo quando estabilizar.

A decisão entre stack e produtividade do time é o mesmo dilema do qual escrevemos em contexto de fragmentação operacional: cada camada tem o seu trade-off ideal, e ignorar isso custa caro.

A lição que fica

A lição não é “use Rust”. É: escolha a ferramenta certa para a camada que está otimizando. A maioria dos orgs de engenharia escolhe linguagem pelo time, não pelo problema — e isso funciona até o dia em que o problema cresce além do que a linguagem aguenta. Quando isso acontece, ter um caminho de migração planejado vale mais do que ter feito a escolha “certa” no dia zero.