Conceito e mecanismo
Uma integração orientada a eventos precisa de distinguir entrega e processamento de negócio. EventBridge aplica retries a falhas elegíveis, com limites de tempo e quantidade. A política predefinida permite até 24 horas e 185 tentativas; não é uma promessa de execução funcional ilimitada. Certos erros, como falta de permissão, podem seguir diretamente para uma DLQ sem retries. Lê os metadados de erro antes de assumir que o contador está errado. Para DLQs de regras, usa SQS standard na mesma Região e configura a política que permite entrega. Uma fila criada por API não garante que essa autorização esteja correta. Observa também falhas de envio para a própria DLQ.
Aplicação guiada
Depois de corrigir a integração, o trabalho acumulado continua a precisar de recuperação. Identifica efeitos já aplicados, inclusive por um procedimento alternativo, e usa identificadores idempotentes e reconciliação. Repete um lote delimitado, observa resultados e amplia apenas quando há evidência. Uma DLQ conserva mensagens; não elimina duplicados nem repete automaticamente todo o negócio. Durante investigação, constrói uma linha temporal com alterações, tráfego, métricas e traces. Latência após uma release é uma hipótese, não prova isolada de causa. A remediação automática deve ter condições de paragem: se restarts repetidos agravam impacto, contém a execução e escala com evidência.
Corrigir uma permissão resolve o caminho de entrega. Os movimentos retidos precisam de comparação com o que já foi tratado manualmente.
Armadilhas comuns
Retry como garantia; DLQ como exatamente uma vez; correção técnica como fecho; correlação como causa raiz.
Tópicos relacionados: Segurança e evidência operacional · Pipeline, artefactos e identidade
Fecha o incidente quando o serviço e o trabalho pendente estão reconciliados.
Referência: EventBridge DLQ · DOP-C02