Dead-letter queue: a quarentena que salva seu sistema
A mensagem envenenada falha, volta e trava a fila para sempre, até existir uma DLQ. Retry com backoff, alarme obrigatório, triagem com destino e o requisito escondido: idempotência.
Toda fila de mensagens tem um vilão anunciado: a mensagem envenenada (poison message). Um JSON malformado, um pedido com dado que o código não previu, um caso de borda que lança exceção. O consumidor falha, a mensagem volta para a fila, o consumidor pega de novo, falha de novo... para sempre. Enquanto isso, as mensagens saudáveis esperam atrás dela, o processamento para, o alerta de fila crescendo dispara às 3h.
A dead-letter queue (DLQ) é a resposta da engenharia madura: depois de N tentativas, a mensagem problemática é movida para uma fila de quarentena, e a vida segue.
A mecânica (simples de propósito)
No SQS, é uma política declarativa (documentação); no RabbitMQ, argumentos da fila apontando para uma dead letter exchange: o conceito é idêntico.
// Redrive policy da fila principal (SQS)
{
"deadLetterTargetArn": "arn:aws:sqs:...:pedidos-dlq",
"maxReceiveCount": 5
}
Tradução: "se a mesma mensagem for recebida 5 vezes sem ser processada com sucesso, mova-a para pedidos-dlq". Cinco linhas de configuração que transformam um travamento total em um incidente isolado e triável.
As decisões que fazem a DLQ funcionar
1. Retry com backoff ANTES de desistir. As primeiras falhas costumam ser transitórias (timeout do banco, dependência reiniciando). O desenho certo dá chances reais: recebimentos espaçados (visibility timeout crescente ou fila de retry com delay), e só então a DLQ. maxReceiveCount: 1 desperdiça a autocura; 50 atrasa a quarentena. A faixa de 3 a 5 serve à maioria.
2. DLQ monitorada ou DLQ inútil. A regra de ouro: qualquer mensagem na DLQ é um alerta, do tipo ticket (horário comercial), com runbook. DLQ sem alarme é onde mensagens vão morrer em silêncio, e "morrer em silêncio" pode significar um pedido não faturado que ninguém percebeu.
3. Triagem com destino. Mensagem na DLQ conta uma história, e cada final pede uma ação:
- Bug no consumidor (o caso mais comum): corrige o código, e faz o redrive (reprocessa a DLQ de volta à fila principal, botão nativo no SQS).
- Dado inválido na origem: conserta na fonte, descarta ou corrige a mensagem manualmente, e registra o caso como aprendizado de validação.
- Mudança de contrato não combinada: alguém alterou o schema do evento; a conversa é sobre versionamento de contratos, não sobre a fila.
4. Retenção generosa na quarentena. A DLQ deve reter por mais tempo que a fila normal (14 dias no SQS, o máximo): incidente descoberto na segunda não pode encontrar a evidência já expirada.
O requisito escondido: reprocessar exige idempotência
Aqui a série se conecta: entre as 5 tentativas originais, o consumidor pode ter processado parcialmente (baixou o estoque e falhou no e-mail?). E o redrive vai reapresentar tudo de novo. Sem consumidores idempotentes (o próximo artigo desta série), o reprocessamento da DLQ transforma um incidente em dois: o original e o dos efeitos duplicados.
Os antipadrões que encontramos por aí
- DLQ compartilhada por várias filas: a triagem vira sopa; uma quarentena por fila principal.
- Reprocessar sem corrigir: redrive imediato sem entender a causa devolve a mensagem para falhar de novo (agora com o contador zerado).
- Tratar a DLQ como lixeira: "se falhou, ignora" descarta exatamente os casos que revelam bugs e dados quebrados. A DLQ é ferramenta de qualidade, não tapete.
- Não testar o caminho da falha: o fluxo mensagem-ruim → retries → DLQ → alarme → redrive merece um teste de verdade, como qualquer fluxo crítico.
O padrão completo, de fábrica
Fila principal + retries com backoff + DLQ com alarme e runbook + consumidores idempotentes: esse é o kit mínimo de mensageria de produção, e é como implantamos qualquer arquitetura assíncrona no nosso serviço de Arquitetura de Software.
Suas filas têm quarentena hoje? Se a resposta é "não sei", provavelmente não. Pergunte à IA da Rabelo Digital, aqui no canto da tela, como adicionar DLQ ao seu broker sem parar o fluxo. Sem formulário, sem espera.
Deixe um Comentário