Uma Dead Letter Queue, ou DLQ, recebe mensagens que não puderam ser processadas ou entregues conforme as regras de uma integração assíncrona. Depois de atingir o limite de tentativas, expirar ou apresentar um erro não recuperável, a mensagem pode ser isolada para diagnóstico, correção e reprocessamento. A DLQ evita que uma mensagem problemática permaneça indefinidamente no fluxo principal, mas exige monitoramento e procedimentos operacionais próprios.
O fluxo prático começa com uma política de tentativa automática para falhas transitórias, como timeout, indisponibilidade temporária de API ou recusa momentânea do gateway. Já erros de payload, contrato quebrado ou dado inconsistente devem seguir para inspeção mais cedo. Em arquiteturas com integração via API e webhooks, esse desenho reduz acúmulo silencioso de falhas e melhora rastreabilidade operacional.
| Tipo de falha | Ação inicial recomendada | Condição antes do reprocessamento |
| Timeout ou indisponibilidade temporária | Retry com backoff | Serviço externo normalizado |
| Limite de requisições | Retry respeitando intervalo e limite | Capacidade ou quota disponível |
| Erro interno transitório | Retry controlado | Causa temporária encerrada |
| Schema incompatível | Encaminhar para DLQ | Contrato ou transformação corrigidos |
| Campo obrigatório ausente | Encaminhar para DLQ | Origem ou enriquecimento corrigidos |
| Regra de negócio recusada | Avaliar se deve haver DLQ ou rejeição definitiva | Decisão funcional registrada |
| Credencial inválida | Suspender o fluxo e gerar alerta | Credencial renovada ou corrigida |
| Mensagem duplicada | Tratar por idempotência | Confirmar que não houve processamento anterior |
| Evento expirado ou sem utilidade | Descartar conforme política | Registrar motivo e auditoria |
Resumo
- O que é Dead Letter Queue e para que serve.
- Diferença entre retry, DLQ e descarte.
- Quais erros devem ou não ser reenviados.
- Como configurar retenção e limite de tentativas.
- Como corrigir e reprocessar mensagens.
- Quais métricas, alertas e controles implementar.
Fatos rápidos
- Implementações diferentes: no Amazon SQS, a DLQ é outra fila que precisa ser criada e associada à fila de origem por uma política de redrive. No Azure Service Bus, cada fila ou assinatura já possui uma subfila de dead letter.
- Sem limpeza universal: no Azure Service Bus, as mensagens permanecem na DLQ até serem recuperadas e concluídas explicitamente. Já em outros serviços, o descarte pode depender da política de retenção configurada.
- RabbitMQ: a plataforma utiliza Dead Letter Exchange. Mensagens podem ser republicadas nesse exchange quando são rejeitadas sem requeue, expiram, ultrapassam o limite da fila ou excedem o limite de entregas de uma quorum queue.
O que é Dead Letter Queue e para que serve?
Em uma integração de sistemas, a Dead Letter Queue isola mensagens que não puderam ser processadas dentro das regras configuradas. A classificação entre falha transitória, erro permanente e descarte deve ser realizada pela aplicação ou pela política de mensageria. Depois de identificar e corrigir a causa, a equipe pode reprocessar a mensagem de forma controlada.
Como configurar uma dead letter queue
Uma política objetiva costuma combinar três elementos: número máximo de tentativas, intervalo progressivo entre tentativas e classificação do erro. O backoff evita tempestade de retries; o limite de tentativas impede laços improdutivos; e a classificação define se a mensagem deve voltar ao fluxo, ir para correção manual ou ser descartada com registro. No padrão Dead Letter Channel, a ideia é retirar do caminho principal aquilo que não pode ou não deve ser entregue naquele momento.
Critérios de retry e segregação
- Retry com backoff para timeout, indisponibilidade e erro 5xx.
- Envio direto à DLQ para schema inválido, chave ausente ou regra de negócio inconsistente.
- Reprocessamento assistido quando há dependência externa normalizada após a falha.
| Cenário | Ação recomendada | KPI associado |
|---|---|---|
| ERP indisponível | Retry com backoff | Tempo de reprocessamento |
| Payload inválido de sensor | DLQ com inspeção | Volume na DLQ |
| Gateway rejeita transação | Classificar erro e decidir retry | Taxa de falha |
Em ambientes distribuídos, monitorar a saúde da fila pede sinais simples e recorrentes. Segundo o Google SRE Book, latency, traffic, errors e saturation formam um conjunto eficiente para acompanhar filas e integrações. Já métricas operacionais como MTTD, MTTR e MTTRepair, tratadas no NIST SP 800-55, ajudam a medir detecção, recuperação e reparo. Em protocolos como MQTT 5.0, a própria especificação da OASIS admite que pacotes descartados possam seguir para uma dead letter queue ou ação diagnóstica.
Confira também estes conteúdos relacionados:
- O modelo de iPaaS ajuda a centralizar integrações, governança e observabilidade.
- O planejamento de um projeto de integração define fluxos de exceção antes da operação crescer.
- A simplificação de integrações complexas reduz acoplamento e acelera resposta a incidentes.
Como corrigir e reprocessar mensagens da DLQ
Quando bem implementada, a dead letter queue deixa de ser apenas uma fila de erro e passa a funcionar como mecanismo de continuidade, diagnóstico e melhoria contínua. Ela preserva o fluxo principal, expõe falhas que exigem correção e cria base para decisões de engenharia mais previsíveis.
Em operações que dependem de integrações entre sistemas, vale tratar esse desenho como parte da governança e manter um canal claro ao entrar em contato com a SysMiddle.
Dead Letter Queue é uma fila ou destino reservado para mensagens que não puderam ser entregues ou processadas conforme as regras definidas.
Ela isola mensagens problemáticas, evita repetição indefinida no fluxo principal e cria um ponto para diagnóstico, correção e reprocessamento.
Retry repete uma operação que pode funcionar depois. A DLQ recebe mensagens que ultrapassaram o limite de tentativas ou precisam de análise antes de voltar ao fluxo.
Não. Algumas falhas devem ser repetidas, outras rejeitadas definitivamente e outras descartadas quando o evento perde a utilidade.
É uma mensagem que falha repetidamente e não será processada com sucesso sem correção em seus dados, contrato, origem ou regra de negócio.
Não existe um número universal. O limite depende da criticidade, do tipo de erro, do tempo de normalização esperado e do custo de repetir a operação.
É uma política que aumenta o intervalo entre as tentativas para não sobrecarregar uma dependência temporariamente indisponível.
É a operação de mover mensagens da DLQ para uma fila de origem ou outro destino a fim de realizar novo processamento.
Não é recomendado. Primeiro é necessário confirmar que a causa foi corrigida e que o reprocessamento não produzirá duplicidades ou efeitos indevidos.
Utilize identificadores únicos, chaves idempotentes e registros das operações já concluídas antes de executar novamente a mesma ação.
O prazo deve permitir detecção, análise e correção. No Amazon SQS, a retenção da DLQ deve ser maior do que a da fila original.
Depende da plataforma. No Azure Service Bus não há limpeza automática; as mensagens permanecem até serem recuperadas e concluídas.
A DLQ é uma fila de destino. No RabbitMQ, o Dead Letter Exchange recebe e roteia mensagens dead-lettered para uma ou mais filas.
Não. A preservação depende da configuração do broker, retenção, permissões, confirmação, disponibilidade e tratamento operacional.
Volume na DLQ, taxa de entrada, idade da mensagem mais antiga, categorias de erro, tempo de resolução, sucesso do redrive e reincidência.
Sim. A entrada ou o crescimento de mensagens deve ser comunicado antes que a fila acumule volume ou atinja o prazo de retenção.
Pode, conforme a finalidade e a arquitetura, mas o payload deve conter somente o necessário e utilizar proteção, retenção e controle de acesso adequados.
