Falha global derrubou Facebook e Instagram no último domingo, 19 de julho. O login não respondia. O feed não carregava. Stories simplesmente não subiam. Para o usuário final, foi um domingo estranho. Para quem escreve código, no entanto, foi uma aula gratuita. A Meta não explicou a causa. Ainda assim, os sintomas dizem muita coisa. Então vamos analisar o que essa pane ensina sobre arquitetura distribuída, observabilidade e resposta a incidentes.

Falha login travado antes do feed: a anatomia de uma pane em cascata

Repare na ordem dos sintomas. Primeiro, o login parou. Depois, o feed e as publicações caíram junto. Esse padrão não é aleatório. Geralmente, quando a autenticação falha, todo o resto desaba atrás dela. Afinal, sem sessão validada, nenhuma requisição autorizada prossegue. Por isso, serviços de auth costumam ser o ponto único de falha mais perigoso de uma stack. Em teoria, eles deveriam ser os mais redundantes. Na prática, porém, centralizam risco. Ou seja, uma falha ali vira uma falha em todo lugar.

Instagram funcionando pela metade? Isso se chama degradação graciosa

Um detalhe passou despercebido nos relatos. Alguns recursos seguiram funcionando durante a pane. Certos usuários abriam o app, mas não postavam. Outros liam o feed, porém não acessavam perfis. Isso não é acaso. Na verdade, é degradação graciosa em ação. Em vez de derrubar tudo, o sistema sacrifica funções não essenciais e mantém o núcleo de pé. Portanto, o app continua parcialmente útil enquanto o incidente rola. Esse é um padrão que você deveria projetar de propósito. Por exemplo, se o serviço de recomendação cai, sirva um feed simples em cache. Assim, o usuário perde qualidade, mas não perde o produto inteiro.

A página de status vazia foi o segundo incidente: Falha

Durante a queda, a Meta disse pouco. A mensagem padrão apontava um problema temporário no site. Nada além disso. Nenhuma causa. Nenhuma previsão real de retorno. E aqui mora o segundo incidente. Comunicação ruim amplia o estrago de qualquer falha. Enquanto o time interno investigava, milhares de pessoas migraram para o Downdetector e outras redes só para confirmar se o problema era geral. Uma status page honesta teria absorvido boa parte dessa ansiedade. Além disso, ela reduz o volume de suporte e preserva a confiança. Ou seja, transparência não é gentileza. É engenharia de incidente.

Blast radius: quando acoplar serviços vira uma armadilha

Facebook e Instagram são produtos diferentes. Mesmo assim, caíram juntos. Isso escancara o quanto eles compartilham por baixo do capô. Provavelmente auth, gateways ou infraestrutura de rede em comum. Quando você compartilha uma dependência crítica, você compartilha também o raio de destruição dela. Esse é o famoso blast radius. Quanto mais serviços dependem do mesmo ponto, maior o estrago quando ele quebra. Logo, isolar domínios vale mais do que parece. Bulkheads, timeouts agressivos e circuit breakers existem justamente para conter o incêndio. Contudo, muita gente só lembra deles depois da falha.

Cinco perguntas para levar ao seu próximo postmortem

Toda falha grande merece um postmortem sem culpados. Aqui vão cinco perguntas para o seu. Primeiro, qual foi o ponto único de falha real? Segundo, quanto tempo levou para detectar o problema? Depois, o sistema degradou com elegância ou caiu por inteiro? Em seguida, a comunicação externa acompanhou o ritmo do incidente? Por fim, o que muda no código para isso não se repetir? Responda com honestidade. Assim, a próxima falha encontra um time mais preparado. No fim das contas, resiliência não se compra pronta. Ela se constrói um incidente de cada vez.

Acompanhe nosso perfil no Instagram!