Skip to main content

Introdução | Padrões de Resiliência | Arquitetura

  • Introdução | Padrões de Resiliência | Arquitetura

Padrões de Resiliência: Timeout, Retry, Retry com Backoff, Circuit Breaker, Bulkhead, Rate Limiting, Throttling, Backpressure, Fallback, Cache, Queue-Based Load Leveling, Health Check, Graceful Degradation, Fail Fast, Idempotência, Dead Letter Queue, Retry Queue, Outbox Pattern, Inbox Pattern, Load Shedding, Hedging, Replication, Failover e Checkpointing

PadrãoO que fazExemplo prático
TimeoutDefine um tempo máximo de espera“Espero no máximo 5s pela API fiscal”
RetryTenta novamente após uma falha transitóriaTimeout, erro 502, conexão recusada
Retry com BackoffTenta novamente, mas aumentando o intervalo1s, depois 2s, depois 5s
Circuit BreakerPara de chamar uma dependência que está falhandoAPI externa caiu, então corto chamadas por 30s
BulkheadIsola recursos para uma falha não afetar tudoFiscal tem 10 threads; pagamento tem 50
Rate LimitingLimita volume de entradaCliente só pode fazer 100 req/min
ThrottlingReduz/controla o ritmo de processamentoWorker processa no máximo 50 msg/s
BackpressureFaz o produtor desacelerar quando o consumidor não acompanhaFila cheia rejeita ou bloqueia novas mensagens
FallbackUsa uma alternativa quando algo falhaSe API externa falhar, usa cache
CacheReduz dependência de chamadas externasConsulta dados frequentes do Redis
Queue-Based Load LevelingUsa fila para absorver picosAPI coloca na fila e worker processa depois
Health CheckVerifica se o serviço está saudável/health, /ready, /live
Graceful DegradationMantém parte do sistema funcionando mesmo com falhaDesativa recomendação, mas pedido continua
Fail FastFalha rápido em vez de esperar travarSe fila está cheia, retorna 429 imediatamente
IdempotênciaPermite repetir operação sem duplicar efeitoMesmo requestId não gera dois pagamentos
Dead Letter QueueGuarda mensagens que não puderam ser processadasMensagem inválida vai para DLQ
Retry QueueReprocessa mensagens com atraso controladoTenta de novo daqui 1min, 5min, 30min
Outbox PatternGarante consistência entre banco e mensageriaSalva pedido e evento na mesma transação
Inbox PatternEvita processar mensagem duplicadaRegistra messageId já consumido
Load SheddingDescarta/rejeita carga para preservar o sistemaRejeita requests não críticas durante pico
HedgingDispara chamada redundante quando uma está lentaChama outra réplica se a primeira demorar
Replication / RedundancyMantém múltiplas instâncias disponíveisMais de uma instância da API rodando
FailoverTroca para instância/região secundáriaBanco primário caiu, usa réplica
CheckpointingSalva progresso para retomar depoisWorker volta do último offset processado