Tratamento de falhas em integrações

Por que falhas acontecem e por que importa

Integrações falham: rede cai (transiente), servidor alvo indisponível (transiente), timeout (transiente), erro de aplicação (permanente), dados inválidos (permanente). Sem tratamento apropriado: transações são perdidas, dados inconsistentes, cascata de falhas. Estudo Netflix mostra que 70% de falhas são transientes (resolvidas com retry)^[1]. Isto significa: automatizar retry resolve maioria dos problemas. Resto requer análise manual ou escalação.

Retry: tentar novamente

Retry tenta novamente requisição que falhou. Apropriado para falhas transientes (rede cai, timeout). Não apropriado para erro de negócio (CPF inválido; retry não ajuda). Risco crítico: retry pode criar duplicata. Exemplo: você tenta transferir R$ 100. Requisição falha na rede. Você retenta. Banco recebe dois pedidos. Sistema transfere R$ 200. Solução: idempotência (requisição repetida resulta em ação única). Como implementar idempotência: use ID único para requisição. Exemplo: "transferência ID-12345, de A para B, R$ 100". Se recebido 2x, ID-12345 já foi processado; retorne sucesso sem repetir.

Exponential backoff e jitter

Exponential backoff: Espera cada vez mais entre retries. Exemplo: 1s, 2s, 4s, 8s (dobra cada vez). Evita sobrecarregar servidor que está indisponível. Alternativa simples: fixed delay (espera sempre 5s) é mais simples mas menos sofisticado. Jitter: Pequena variação aleatória em delay (evita "thundering herd" — 1000 clientes esperando 1s, todos retentam ao mesmo tempo). Exemplo: delay é 1-3s (variável). Implementação prática: retry 1 (falha) > espera 1s > retry 2 (falha) > espera 2s > retry 3 (falha) > espera 4s > retry 4 (sucesso ou abandono).

Circuit breaker: proteção contra cascata

Circuit breaker detecta que servidor alvo está down. Interrompe requisições por período (tipicamente 30s). Retorna erro rápido ao invés de esperar timeout (que pode ser 30s). Estados: (1) Closed (normal, requisições passam). (2) Open (alvo está down, requisições retornam erro rápido). (3) Half-open (alvo pode estar recuperado, tenta 1 requisição; se sucesso, volta para Closed). Benefício: proteção contra cascata. Servidor A falha. B para de chamar A (circuit aberto). B não gasta recursos esperando A. C que depende de B não afetado tão severamente. Exemplo: Google Pub/Sub usa circuit breaker. Se seu subscriber está down por 30s, subscriber é temporariamente desabilitado. Quando volta, reconnecta.

Dead letter queue: análise manual de falhas

Mensagem que falha é armazenada em fila separada (Dead Letter Queue) para análise/reprocessamento manual. Exemplo: validação é ambígua (email é válido? talvez). Humano analisa, decide, reprocessa. Cenário: cliente envia email "abc@" (inválido). Sistema tenta processar. Falha em validação. Ao invés de abandonar, vai para DLQ. Operador vê, corrige email, reprocessa. Importante: DLQ é "catch-all para problemas que sistema não consegue resolver automaticamente". Não é para tudo; é para exceções.

Idempotência: segurança para retry

Se requisição for repetida (retry), resultado é idêntico. Crítico para retry seguro. Exemplo de NÃO-idempotente: "transferir $100". Se executado 2x, resultado é $200 transferido (errado). Exemplo de idempotente: "transferência ID-12345, $100". Se executado 2x com mesmo ID, resultado é $100 transferido uma vez. Sistema reconhece ID já foi processado; não executa novamente. Implementação: use ID único (UUID, request ID). Sistema rastreia IDs processados. Requisição chegando com ID já processado = sucesso sem ação.

Compensação: desfazer ação em falha

Se integração falha parcialmente (A foi feito, B falhou), desfazer A (compensação). Padrão saga coordena múltiplas integrações, mantém consistência mesmo com falhas. Exemplo: criar pedido requer: (1) Criar ordem em ERP (sucesso). (2) Atualizar inventário (falha). Sem compensação: ordem existe, inventário não foi decrmentado (inconsistência). Com compensação: detecta falha em passo 2, executa compensação em passo 1 (delete ordem). Final state: nada feito. Implementação: cada ação tem "undo action". Sistema executa sequencial; se uma falha, executa undo reverso.

Perguntas frequentes

Como tratar falhas em integrações?

Implementar: (1) retry com exponential backoff, (2) idempotência para evitar duplicação, (3) circuit breaker para proteção contra cascata, (4) DLQ para análise manual de exceções.

O que é retry e exponential backoff?

Retry tenta novamente. Exponential backoff aumenta delay entre tentativas (1s, 2s, 4s...) evitando sobrecarregar servidor. Jitter adiciona variação aleatória.

Circuit breaker em integrações: quando usar?

Quando múltiplos consumidores chamam servidor. Circuit breaker detecta servidor down, para requisições rapidamente. Evita cascata de falhas.

Como implementar dead letter queue?

Quando mensagem falha e não pode ser automaticamente reprocessada, vai para DLQ. Operador analisa, corrige, reprocessa manualmente.

Recuperação de falhas em integração: estratégias?

Retry para transientes. Circuit breaker para proteção. DLQ para exceções. Compensação para reverter ações parciais. Combinação é apropriada.

Compensação de transações em integrações?

Se ação A sucesso, ação B falha, executar "undo A" para manter consistência. Padrão saga coordena múltiplas ações, compensação em cascata.

Referências

1. Netflix. "Chaos Engineering and Release It! Patterns."
2. Resilience4j Documentation. "Retry, Circuit Breaker, Rate Limiter Patterns."
3. Google SRE Book. "Handling Overload and Cascading Failures."