cascading-failures

SRE — Addressing Cascading Failures

Quando usar

LLM carrega esta skill ao analisar serviço com risco de cascade, ou durante incident em progresso onde failure se amplifica. Trigger phrases:

• "cascading failure", "falha em cascata"
• "retry storm", "thundering herd"
• "outage propagando", "serviço caindo um após outro"
• "como prevenir cascade?", "circuit breaker"
• "cap 22 Google SRE"
• "deadline propagation", "load shedding"

Regras absolutas

• Cascade tem 5 triggers canônicos: server overload, resource exhaustion, service unavailability, latency spike sem timeout, retry sem jitter. Memorize-os.
• Prevenção custa 1×, recuperação custa 100×. Toda dep crítica DEVE ter timeout + retry com jitter + circuit breaker + deadline propagation. Sem isso, cascade é questão de tempo.
• Saturation (cap 6 v1.10) é early warning de cascade. Quando saturation > 80%, ainda há tempo. Quando hit 100%, já está em cascade.
• Retry SEMPRE com jitter. Full jitter por default (delay = random(0, base × 2^attempt)). Sem jitter = thundering herd garantido.
• Retry SEMPRE com deadline. Retry sem timeout amplifica cascade — call de 30s vira 90s vira 270s. Deadline propagation evita work zumbi.
• Circuit breaker DEFAULT em qualquer dep externa. Estados closed/open/half-open. Open dispara após N failures consecutivas; half-open permite 1 probe; closed após probe verde.
• Load shedding > 503 graceful > queue overflow. Server saturated DEVE retornar 503 com Retry-After ANTES de aceitar request que vai falhar. Aceitar e cair = pior que rejeitar.
• Slow start em recovery. Após outage, ramp-up gradual (10% → 25% → 50% → 100%). Full blast em recovery = falha de novo (caches frios, conn pools).

Patterns canônicos

Pattern 1: 5 triggers canônicos de cascade (cap 22)

1. SERVER OVERLOAD
   Sintoma: load > capacity → latency p99 sobe 10× → errors 5xx → crashes
   Trigger upstream: traffic spike, outage de cache, batch job rodou em horário ruim
   Detect: Saturation gauge (cap 6) > 80% por > 5 min
   Resposta: load shedding + escalação manual

2. RESOURCE EXHAUSTION
   Tipos: CPU, memory, file descriptors, threads, connection pool
   Sintoma específico:
     CPU 100% → latency sobe; FDs esgotados → "too many open files"
     Memory OOM → process kill; threads → deadlock; conn pool empty → wait
   Detect: monitor por recurso específico; alarmes em 80% de cada
   Resposta: configure limits; circuit breaker; rate limit caller

3. SERVICE UNAVAILABILITY (DEP DOWN)
   Sintoma: dep externa retorna 5xx ou timeout. Sem circuit breaker:
   N clients × M retries × T deadline = explosão de calls
   Detect: error rate de dep > 50% por 1 min; latency dep > p99 normal × 5
   Resposta: circuit breaker abre; fallback (cache, default value, degraded mode)

4. LATENCY SPIKE SEM TIMEOUT
   Sintoma: dep responde lento mas não falha. Caller fica esperando.
   Conn pool de caller esgota; novos requests também ficam pendurados.
   Detect: dep latency p99 > baseline × 5
   Resposta: timeout AGRESSIVO (ex: p99.9 baseline + 50%); circuit breaker

5. RETRY SEM JITTER
   Sintoma: 1000 clients retentam ao mesmo tempo após dep recovery.
   Server recém-recuperado é matado pelo wake-up.
   Detect: traffic spike no momento exato de recovery
   Resposta: full jitter; retry budget global; slow start