Elixir Fault Tolerance em Produção

Quis trazer um pouco sobre o que acho do Elixir e sobre o motivo de ter trocado todo o Backend da minha plataforma de Node.JS (nest) para Elixir, me trouxe muita tranquilidade em cada deploy.

Quando comecei a lidar com problemas reais de produção na BlibSend, ficou claro que fault tolerance não é sobre “se o sistema vai falhar”, mas como ele falha.

Em sistemas distribuídos, falha é regra:

• Rede cai
• Serviço externo oscila
• processo entra em estado inválido
• Mensagens chegam duplicadas

O erro é achar que dá para prever tudo isso com try/catch e lógica defensiva.
No core da BlibSend, optei por tratar falha no nível mais baixo possível: o processo.

Em Elixir, cada processo é leve, isolado e descartável, eles não compartilham memória. Quando um quebra, não contamina o resto do sistema.

Isso muda completamente a abordagem, em vez de escrever código tentando impedir qualquer erro, o sistema é desenhado para:

• deixar o processo falhar
• Reiniciar rapidamente
• continuar operando normalmente

O papel do código deixa de ser “nunca falhar” e passa a ser "falhar bem", a supervisão entra exatamente aí.

Cada parte crítica roda sob um supervisor com uma estratégia clara:

• Isolar falhas quando possível
• Reiniciar só o que quebrou.
• evitar reinícios em cascata

Nada de restart geral.
Nada de downtime desnecessário.

Outro ponto essencial: estado.

Na BlibSend, processos não são fonte de verdade, eles são apenas executores temporários, o estado real vive no PostgreSQL, que funciona como single source of truth.
Se um processo morre, outro sobe e continua a partir do estado persistido.

Com filas baseadas em banco (Oban e pg-boss):

• Jobs podem falhar e ser reprocessados.
• Retries são previsíveis
• Idempotência é tratada como requisito

Isso traz uma tranquilidade enorme em produção.

Fault tolerance não é sobre impedir que algo dê errado, é aceitar que vai dar e garantir que: o impacto seja pequeno e o sistema siga funcionando

No fim, tolerância a falhas é uma decisão de arquitetura, não uma feature, e quanto mais cedo isso entra no desenho do sistema, menos dor aparece lá na frente.

Vou criar um blog, sendo mais específico, como apliquei tudo na prática, só consegui um tempo.