O pitch
Dez por cento de todos os crashes do Firefox registrados em campo resultam de bitflips espontâneos causados por instabilidade de hardware, e não por defeitos de software. Esses dados de telemetria confirmam que nem o código mais otimizado consegue compensar as falhas de confiabilidade inerentes ao silício de consumo.
Por dentro
A telemetria da Mozilla identifica estados de CPU “impossíveis” que apontam diretamente para Single Event Upsets (SEUs) como a causa de um volume significativo de crashes “impossíveis de corrigir” (Fonte: Gabriele Svelto, Mastodon). Essa quantificação coincide com dados históricos da ArenaNet, onde verificações matemáticas em segundo plano identificaram, em 2004, bitflips em 1 a cada 1000 máquinas clientes (Fonte: HN).
Os ambientes de produção modernos mostram padrões semelhantes: o runtime.SetCrashOutput do toolchain Go já revelou centenas de crashes induzidos por hardware que antes teriam sido registrados como bugs de lógica obscuros (Fonte: mantenedor do Go). Esperar que a RAM de consumo seja confiável é como esperar que um político responda a uma pergunta direta: otimista, mas no fim das contas inútil.
A indústria de hardware tentou mitigar o problema com a DDR5, mas o marketing do “on-die ECC” é em grande parte uma cortina de fumaça. Ele não oferece proteção de ponta a ponta para os dados em trânsito até a CPU, o que deixa o hardware de consumo de 2026 vulnerável à corrupção silenciosa de dados (consenso técnico).
Ainda não sabemos se os navegadores baseados em Chromium observam o mesmo patamar de 10%, pois dados comparativos semelhantes continuam indisponíveis.
Nossa opinião
Pare de desperdiçar sprints de engenharia tentando depurar condições de corrida “impossíveis” que só aparecem na telemetria de campo. Se você roda serviços de backend de alta carga ou inferência de LLM em hardware sem ECC completo no sistema, está basicamente apostando contra os raios cósmicos. Esses dados provam que 10% dos seus problemas de estabilidade não são culpa sua, mas mitigá-los é responsabilidade sua, por meio de paridade de hardware, e não de mais testes unitários.