Quando a Redundância Não Basta: Lições de Uma Queda Inesperada

Muita gente acredita que espalhar aplicações por diferentes provedores é garantia de estabilidade. AWS, Google Cloud e servidores próprios pareceriam uma combinação imbatível contra falhas isoladas. No papel, faz sentido.

A Railway, plataforma de deploy moderna, seguia exatamente essa estratégia. Suas aplicações rodavam distribuídas entre Google Cloud, AWS e a própria infraestrutura da empresa. Parecia seguro.

Mas em uma noite de maio de 2026, tudo parou. O Google Cloud suspendeu automaticamente a conta da Railway sem aviso prévio. Não foi uma falha técnica nos servidores. Foi um sistema automatizado que detectou algo suspeito e agiu por conta própria.

Quando o Controle Fica Centralizado

O problema não estava nas aplicações em si. Elas continuaram funcionando normalmente nos outros provedores. O que quebrou foi a parte responsável por direcionar o tráfego.

Toda requisição que chega a uma aplicação na Railway passa primeiro por proxies na borda da rede. Esses proxies precisam saber onde cada aplicação está rodando no momento. Essa informação fica em um sistema central — o control plane.

Quando o Google Cloud bloqueou a conta, esse sistema ficou inacessível. Por cerca de 35 minutos, os proxies conseguiram continuar funcionando graças a um cache local. Depois, os dados expiraram e as requisições começaram a receber erro 404, mesmo com as aplicações perfeitamente intactas.

Quando Uma Falha Gera Outras

A situação ainda piorteou. O grande volume de requisições com erro fez com que GitHub aplicasse limites de requisição nos endpoints de OAuth da Railway. Isso blockeou o login de usuários e o trigger de new deployments. Mesmo depois da recuperação do control plane, a segunda falha ainda impediu acesso.

O Que Mudar em Sua Arquitetura

O episódio da Railway mostra que distribuir as workloads não é o mesmo que distribuir o controle sobre elas. Muitos projetos investem em multi-cloud para evitar falhas, mas deixen o sistema que coordena tudo em um único provedor.

Alguns pontos para refletir:

• Control plane e data plane não são iguais — Computação distribuída é fácil de visualizar. Mas se o routing, o serviço de descoberta e a orquestração ficam concentrados em um só lugar, a redundância vira fachada.
• Cache é paliativo — Ele compra tempo, but não resolve o problema. Quando o cache expira, o problema volta.
• Falhas em cadeia são rápidas — Um erro pode acionar limites de requisição em outros serviços, complicando ainda mais a recuperação.
• Entenda os sistemas automáticos — Conversar com seu provedor sobre triggers de suspensão e ter escalas de emergência pode evitar que um bloqueio inesperado afete toda a infraestrutura.

Railway já anunciou que vai distribuir também o control plane entre AWS e sua própria infraestrutura. Isso costuma ser um trabalho pesado, mas é o que realmente evita problemas desse tipo.

Para quem planeja setups multi-cloud, a lição é clara: procure por pontos únicos de dependência — mesmo que estejam escondidos dentro dos sistemas de controle.