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 exceder tentativas, apresentar um erro não recuperável ou atender a outra condição configurada, a mensagem pode ser isolada para diagnóstico e eventual reprocessamento sem permanecer bloqueando o fluxo principal.
A DLQ, porém, não resolve o erro sozinha. Ela precisa fazer parte de uma estratégia que defina quais falhas merecem retry, quando interromper as tentativas, como identificar duplicidades, quanto tempo preservar as mensagens, quem deve receber alertas e em quais condições o redrive é seguro.
Resumo
- Dead Letter Queue isola mensagens que não puderam seguir pelo fluxo normal.
- Retry deve ser reservado principalmente a falhas potencialmente transitórias.
- Erros permanentes não devem ser repetidos indefinidamente.
- Redrive só deve acontecer depois que a causa da falha for corrigida.
- Idempotência é necessária para evitar efeitos duplicados após novas tentativas.
- Volume da DLQ, idade das mensagens e tempo de resolução precisam ser monitorados.
O que é Dead Letter Queue?
Dead Letter Queue é uma fila ou destino reservado para mensagens que não puderam ser processadas normalmente dentro de uma arquitetura de mensageria.
Imagine um consumidor recebendo uma mensagem para criar um pedido no ERP. Se o ERP estiver temporariamente indisponível, uma nova tentativa pode resolver. Mas, se o payload estiver sem um campo obrigatório, repetir a mesma mensagem vinte vezes não corrigirá o dado.
A DLQ permite retirar essa mensagem problemática do caminho principal para que as demais continuem sendo processadas.
Depois, a equipe pode investigar por que ela falhou, corrigir a causa e decidir se deve reprocessar, rejeitar definitivamente ou descartar a mensagem.
Qual é a diferença entre retry e Dead Letter Queue?
Retry é uma nova tentativa de executar uma operação. DLQ é um destino para retirar uma mensagem problemática do fluxo normal.
| Situação | Ação provável | Antes de tentar novamente |
|---|---|---|
| Timeout | Retry com backoff | Respeitar limite e idempotência |
| API temporariamente indisponível | Retry controlado | Confirmar possibilidade de recuperação |
| Rate limit | Aguardar e repetir | Respeitar janela ou Retry-After |
| Schema inválido | DLQ | Corrigir contrato ou transformação |
| Campo obrigatório ausente | DLQ | Corrigir origem ou enriquecimento |
| Credencial expirada | Suspender e alertar | Renovar a credencial |
| Mensagem duplicada | Idempotência | Confirmar processamento anterior |
| Evento sem utilidade após determinado prazo | Descartar conforme política | Registrar decisão e motivo |
Isso evita um erro comum: transformar retry em uma repetição automática de mensagens que nunca terão chance de funcionar.
O que é uma poison message?
Poison message é uma expressão usada para uma mensagem que falha repetidamente e não tende a ser processada com sucesso sem alguma intervenção.
O problema pode estar no próprio payload, em uma incompatibilidade de schema, em uma regra de negócio, em uma referência inexistente ou em outra condição permanente.
Se essa mensagem continuar voltando imediatamente para a fila principal, pode consumir capacidade de processamento e esconder o problema real.
A DLQ cria um lugar específico para investigá-la sem prejudicar as mensagens saudáveis.
Como funciona uma Dead Letter Queue?
O comportamento exato varia entre brokers e serviços de mensageria, mas um fluxo típico pode funcionar assim:
- uma mensagem chega à fila;
- o consumidor tenta processá-la;
- uma falha ocorre;
- a aplicação classifica a falha;
- se for transitória e elegível, há nova tentativa;
- depois do limite configurado ou diante de um erro permanente, a mensagem é dead-lettered;
- um alerta ou rotina operacional identifica a ocorrência;
- a causa é corrigida;
- a mensagem pode ser reenviada para processamento quando isso for seguro.
Como definir a quantidade de retries?
Não existe um número universal de tentativas.
Um limite adequado depende principalmente de:
- tipo de falha;
- tempo esperado para recuperação da dependência;
- criticidade da operação;
- custo de cada tentativa;
- volume de mensagens;
- latência máxima aceitável;
- garantias de idempotência.
Uma política agressiva demais pode sobrecarregar justamente o serviço que já está apresentando dificuldade. Uma política curta demais pode mandar para a DLQ mensagens que teriam sido processadas normalmente alguns segundos depois.
O que é retry com backoff?
Retry com backoff significa aumentar ou controlar o intervalo entre novas tentativas em vez de repetir a operação imediatamente e sem pausa.
Se uma API estiver sobrecarregada, por exemplo, centenas de consumidores repetindo chamadas em sequência podem agravar a indisponibilidade.
Também é comum adicionar uma variação aleatória, ou jitter, aos intervalos para reduzir a possibilidade de vários clientes repetirem suas solicitações exatamente ao mesmo tempo.
Como funciona a DLQ no Amazon SQS?
No Amazon SQS, a DLQ é outra fila que precisa ser criada antes de ser associada à fila de origem.
A redrive policy define o maxReceiveCount, ou seja, quantas vezes uma mensagem pode ser recebida da fila de origem antes de ser movida para a DLQ.
A AWS alerta que um valor muito baixo pode enviar para a DLQ uma mensagem depois de uma falha que seria apenas transitória.
A plataforma também permite posteriormente fazer DLQ redrive, movendo mensagens de volta para processamento.
Outro cuidado importante é a retenção. Para filas SQS Standard, a AWS recomenda configurar a retenção da DLQ com um período maior do que o da fila original.
Há ainda uma particularidade de filas FIFO: utilizar uma DLQ pode romper a ordem exata esperada entre operações. Em processos nos quais a sequência é crítica, esse impacto precisa entrar no desenho.
Como funciona no Azure Service Bus?
No Azure Service Bus, cada fila e cada subscription de um tópico já possui uma subfila de dead letter.
Ela não precisa ser criada separadamente e não pode ser gerenciada independentemente da entidade principal.
Entre as causas que podem levar mensagens à DLQ estão:
- excesso do número máximo de entregas;
- expiração, quando a configuração de dead lettering por TTL estiver habilitada;
- problemas relacionados a sessions;
- excesso do limite de hops em auto-forward;
- dead lettering explícito feito pela própria aplicação.
O valor padrão de MaxDeliveryCount é 10.
Outra diferença importante é que mensagens na DLQ não são automaticamente apagadas por TTL. Segundo a Microsoft, elas permanecem até que sejam explicitamente recuperadas e concluídas.
Como funciona no RabbitMQ?
No RabbitMQ, o conceito técnico utilizado é Dead Letter Exchange, ou DLX.
Quando uma mensagem é dead-lettered, ela é republicada nesse exchange e então roteada conforme os bindings configurados.
De acordo com a documentação oficial do RabbitMQ, isso pode acontecer quando:
- o consumidor rejeita a mensagem sem requeue;
- a mensagem expira por TTL;
- a fila ultrapassa seu limite de tamanho;
- uma quorum queue ultrapassa o delivery limit configurado.
Nas quorum queues, o RabbitMQ 4.0 e versões posteriores utilizam delivery limit padrão de 20. Se esse limite for ultrapassado, a mensagem pode ser descartada ou dead-lettered quando um DLX estiver configurado.
Isso mostra por que “DLQ” não deve ser tratada como uma funcionalidade idêntica em todas as tecnologias. A finalidade é semelhante, mas o mecanismo e as garantias variam.
O que é redrive?
Redrive é o processo de retirar mensagens de uma DLQ e encaminhá-las novamente para processamento.
Mas reenviar não deve ser o primeiro passo.
Antes do redrive, a equipe precisa confirmar:
- por que a mensagem falhou;
- se a causa foi corrigida;
- se o payload ainda é válido;
- se a operação ainda faz sentido para o negócio;
- se a mensagem já produziu algum efeito parcial;
- se o reprocessamento é idempotente.
O próprio Azure Service Bus permite recuperar uma mensagem, corrigir conteúdo ou propriedades quando necessário e reenviá-la para processamento depois que o problema foi resolvido.
Por que idempotência é importante no reprocessamento?
Imagine uma mensagem responsável por criar uma cobrança.
O serviço de destino pode ter criado a cobrança corretamente, mas a conexão cair antes de devolver a confirmação. A aplicação interpreta a operação como falha e a mensagem posteriormente chega à DLQ.
Se ela for simplesmente reenviada, pode gerar uma segunda cobrança.
Por isso, operações críticas precisam usar mecanismos como identificadores únicos, chaves idempotentes ou consulta do estado anterior antes da repetição.
Uma DLQ pode virar um cemitério de mensagens?
Sim. Esse é um dos maiores riscos de uma implementação incompleta.
Criar uma DLQ e não definir alertas, responsáveis e procedimentos apenas transfere o problema para outra fila.
Em uma publicação no LinkedIn, expliquei que as arquiteturas de integração mais sólidas que encontro se apoiam em três pilares: observabilidade, desacoplamento e governança. Para mim, a DLQ só gera valor quando está conectada a esses três pontos. A fila desacopla a falha do fluxo principal, a observabilidade permite detectá-la e a governança define quem deve resolver e como reprocessar.
Sem isso, uma fila pode acumular milhares de mensagens enquanto o primeiro alerta real chega por meio do usuário ou do cliente.
Quais métricas acompanhar em uma DLQ?
| Métrica | O que indica |
|---|---|
| Quantidade de mensagens | Tamanho atual do problema acumulado |
| Taxa de entrada | Velocidade com que novas falhas chegam à DLQ |
| Idade da mensagem mais antiga | Há quanto tempo existe uma falha ainda não resolvida |
| Falhas por categoria | Principais causas recorrentes |
| Tempo até detecção | Quanto demora para o problema gerar ação |
| Tempo até resolução | Quanto demora para corrigir a causa |
| Sucesso do redrive | Percentual reprocessado depois da correção |
| Reincidência | Mensagens que voltam à DLQ depois do redrive |
A métrica isolada também precisa de contexto. Dez mensagens podem ser irrelevantes em uma fila de milhões ou representar a interrupção total de um processo crítico de faturamento.
Quando uma DLQ deve gerar alerta?
Em integrações críticas, não é recomendável esperar o volume crescer para descobrir o problema.
Os alertas podem levar em conta:
- primeira mensagem na DLQ;
- taxa de crescimento;
- idade máxima;
- tipo de erro;
- cliente ou processo afetado;
- criticidade da integração.
O alerta precisa conter informação suficiente para orientar uma ação: mensagem, integração, sistema, motivo, horário, correlation ID e responsável são exemplos úteis.
Como corrigir e reprocessar mensagens da DLQ?
- Identifique a causa: analise payload, erro, logs e dependências envolvidas.
- Classifique o problema: determine se é dado, contrato, autenticação, infraestrutura ou regra de negócio.
- Corrija a causa: alterar apenas a mensagem pode não resolver o defeito que continuará produzindo novas falhas.
- Valide efeitos anteriores: confirme se nenhuma parte da operação já foi executada.
- Teste o reprocessamento: quando possível, valide primeiro em ambiente ou lote controlado.
- Execute o redrive: reenvie somente as mensagens elegíveis.
- Acompanhe o resultado: verifique sucesso, reincidência e impacto no fluxo.
Dead Letter Queue faz parte da continuidade da integração
Uma DLQ bem desenhada impede que uma mensagem problemática paralise ou contamine o restante do processamento, mas sua função vai além de “guardar erros”.
Ela precisa estar conectada a critérios claros de retry, idempotência, observabilidade, alertas, retenção, responsabilidade e reprocessamento.
Quando esses elementos existem, a fila de dead letter ajuda a transformar falhas inevitáveis em eventos controláveis e investigáveis.
A SysMiddle estrutura integrações com monitoramento, tratamento de erros e capacidade de reprocessamento para que falhas entre APIs, ERPs, plataformas e sistemas legados possam ser identificadas antes de comprometer toda a operação.
Se suas integrações acumulam erros silenciosamente ou dependem de intervenção manual sempre que um sistema fica indisponível, fale com um especialista da SysMiddle.
Perguntas frequentes sobre Dead Letter Queue
É uma fila ou destino reservado para mensagens que não puderam ser processadas ou entregues conforme as regras definidas para o fluxo principal.
Retry repete uma operação que ainda pode funcionar. A DLQ isola mensagens que excederam tentativas ou precisam de correção antes de voltar ao processamento.
Não. Falhas transitórias podem receber retry, algumas mensagens podem ser rejeitadas definitivamente e eventos sem utilidade podem ser descartados conforme uma política registrada.
É o reenvio de mensagens da DLQ para novo processamento depois que a causa da falha foi identificada e corrigida.
Não existe um número universal. O limite depende do tipo de erro, criticidade, tempo esperado de recuperação, volume, custo das tentativas e garantias de idempotência.
Acompanhe volume, taxa de entrada, idade da mensagem mais antiga, causas de erro, tempo até resolução, sucesso do redrive e reincidência após reprocessamento.
