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 é o coração da infraestrutura de APIs da Google Cloud. Este binário regional gerencia autenticação, quota enforcement e policy checks para TODAS as requisições de API. Quando ele falha, toda a stack cai junto.
Service Control é um serviço regional com datastore Spanner que gerencia políticas de quota globalmente. Metadados replicam instantaneamente entre 42 regiões para enforcement de quota consistente.
29 de maio: Nova feature para quota policy checks foi deployada. Código tinha path nunca testado. 12 de junho: Policy update com campos em branco triggou o path não testado → null pointer → crash loop.
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.
Este incident expôs gaps críticos em design de sistemas distribuídos. Cada falha aqui é uma masterclass em como NÃO projetar infraestrutura crítica.
Service Control será modularizado para fail open. Se policy check falha, API request deve prosseguir. Princípio fundamental: availability over consistency.
TODAS mudanças em binários críticos serão feature flag protected e disabled by default. Rollout gradual region-by-region, projeto interno primeiro.
Testing de paths não exercitados via chaos engineering. Inject failures regulares para descobrir edge cases antes que cheguem em produção.
Implementar randomized exponential backoff em TODOS os clients. Evitar herd effects que sobrecarregam backends durante recovery.
Metadados críticos não podem replicar globalmente instantaneamente. Implementar staged rollout com validation e monitoring entre regiões.
Monitoring e communication infrastructure devem ser independentes da primary stack. Out-of-band monitoring para detectar falhas quando tudo está down.