Um provedor de pagamento começa a responder com 500 e sua fila de jobs engorda a cada minuto. Workers ficam presos esperando timeout de 30 segundos por chamada. Requisições novas entram, não encontram worker livre e o serviço inteiro responde lento. Michael Nygard documentou essa cascata em Release It! (Pragmatic Bookshelf, 2ª ed., 2018); quatro padrões cortam o efeito antes do colapso.

Circuit breaker em três estados

O breaker conta falhas por dependência. Acima do threshold, ele abre: chamadas seguintes falham rápido, sem tocar a rede. Cooldown passa, o breaker entra em meia-abertura e deixa uma chamada de teste atravessar. Sucesso devolve o breaker ao estado fechado; falha o reabre. A implementação vive na borda da chamada externa, e o time registra transição de estado como métrica por dependência. Alerta dispara quando o breaker abre, não quando a latência média sobe.

Retry com backoff exponencial e jitter

Retry imediato diante de falha cria tempestade: mil clientes reentram juntos e derrubam o serviço que estava se recuperando. Backoff exponencial dobra o intervalo a cada tentativa. Jitter espalha as tentativas no tempo e evita sincronização. Só operação idempotente entra no loop de retry: criar cobrança de novo gera duplicata; reprocessar webhook com chave de idempotência, não. O guia de arquitetura da AWS recomenda jitter aleatório junto do backoff (AWS, 2015), e a conta de sincronização em massa aparece em qualquer incidente pós-Black Friday.

Timeout em toda chamada e bulkhead

Timeout de conexão e timeout de leitura separam falha de rede de resposta lenta. Padrão bulkhead isola recursos por dependência: pagamento usa pool de 20 threads, email usa outro pool. Falha em um não drena o outro. A Netflix criou Hystrix para isso e o aposentou em 2018; times Java migraram para Resilience4j, que compõe breaker, retry, bulkhead e rate limiter como funções independentes. Documentação do Resilience4j (2025) mostra a composição por módulo.

Medir o que o breaker faz

Você registra por dependência: taxa de erro, latência p99, duração de cada estado do breaker e quantas chamadas o fallback atendeu. Sem isso, o breaker vira caixa-preta que falha sozinho e ninguém sabe se protegeu o serviço ou escondeu o problema. Sam Newman, em Building Microservices (O'Reilly, 2ª ed., 2021), coloca resiliência de dependências ao lado de observabilidade: o padrão paga o custo quando o time enxerga a falha e escolhe o comportamento de fallback.