Carregando
Análise técnica profunda de como um null pointer exception no binário Service Control da Google Cloud causou crash loop global, afetando 86+ serviços por 3 horas e gerando 1.4M+ reports de outage mundial.
Um null pointer exception em código não testado no binário Service Control da Google Cloud propagou-se globalmente em segundos, derrubando Gmail, YouTube, Spotify, Discord e 80+ outros serviços por 3 horas. Uma lição impactante sobre fail-safe design.
Service Control é tipo o coração batendo na infraestrutura de APIs da Google Cloud. Esse binário regional cuida de autenticação, controla quotas e valida políticas pra TODAS as requests de API. Quando ele morre, a stack inteira desaba.
Service Control roda regional com datastore Spanner, gerenciando políticas de quota no mundo inteiro. Metadados se espalham em segundos pelas 42 regiões pra manter quota consistente.
29 de maio: nova feature de quota policy checks no ar. O código tinha um caminho que ninguém testou. 12 de junho: policy update com campos vazios ativa o caminho não testado → null pointer → crash loop infinito.
Como um único null pointer propagou-se através de sistemas distribuídos globais
Metadados de policy replicaram globalmente em segundos via Spanner. Cada região exercitou o bad path simultaneamente.
Service Control restart simultâneo sobrecarregou Spanner backend. Falta de exponential backoff agravou o problema.
API Gateway rejeitou todas requests. Serviços downstream falharam em cadeia. Monitoring próprio da Google também falhou.
Esse incidente mostrou buracos críticos no design de sistemas distribuídos. Cada erro aqui é aula de como NÃO construir infra crítica.
Service Control vai virar modular e fazer fail open. Se policy check falhar, request continua. Regra de ouro: disponibilidade antes de consistência.
Toda mudança em binário crítico vai ter feature flag e vir desabilitada. Rollout gradual região por região, projetos internos primeiro.
Testar caminhos não usados via chaos engineering. Injetar falhas direto pra descobrir edge cases antes de virar problema em produção.
Botar randomized exponential backoff em todos os clients. Evita herd effect que sobrecarrega backend na hora da recuperação.
Metadados críticos não dá pra replicar no mundo todo de uma vez. Fazer staged rollout com validação e monitoramento entre regiões.
Infra de monitoring e comunicação tem que ser separada da stack principal. Out-of-band monitoring pra detectar quando tudo cai.