Dead-Letter Queue

Fila auxiliar que recebe, via Dead-Letter Exchange do RabbitMQ, a mensagem rejeitada sem requeue ou expirada na fila principal. Evita as duas saídas ruins — retry infinito e descarte silencioso — e deixa a mensagem estacionada para inspeção, alerta e reprocessamento controlado.

passos: 6
arquivos: 9
teste: 1
tecnologias: 5

Infraestrutura realTypeScriptBunRedisRabbitMQDocker

Cenário Relações Comparar

Baixar cartão

Cenário

Um banco digital processa PIX, TED e boleto. O PIX-002 falha uma vez e é liquidado no retry; a TED-003 esgota os retries com o clearing fora do ar; o BOL-005 é recusado (boleto já pago); o BOL-004 chega corrompido (poison pill). Os três mortos vão para a DLQ; a inspeção alerta cada um, descarta os boletos e, com o clearing de volta, republica a TED, que é liquidada.

Como funciona

6 passos

Isola a mensagem que falhou demais.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

ack+12

nack+6

x-death+3

x-dead-letter-exchange+1

Dead-Letter Queue (DLQ)

payments.dlq+1

AMQP Message Handler

x-attempt+1

RabbitMQ — liquidação de pagamentos com retry e DLQ

01
DLXpayments.queue declara x-dead-letter-exchange e x-message-ttl — rejeitada sem requeue ou expirada, o broker entrega à payments.dlq
02
Poison pill e recusaCorpo inválido ou erro de negócio vai direto para a DLQ, sem retry
03
Falha transitóriaRetry atrasado por filas de TTL fixo, com x-attempt no header; esgotado o último degrau, DLQ — nunca nack com requeue em loop
04
DiagnósticoA mensagem leva serviço de origem, correlation id e horário; o broker carimba motivo e fila de origem no x-death
05
InspeçãoToda mensagem da DLQ é lida, alertada e confirmada (ack), mesmo quando descartada
06
Reprocessamento controladoCom a causa corrigida, a mensagem volta à fila principal com o mesmo id — a idempotência do worker (Redis) segura duplicata

apps/patterns/dead-letter-queue

9 arquivos

src/

topology_payment.tsExchange, fila com DLX e TTL, DLQ e filas de retry
publisher_payment.tsPublicação confirmada com mandatory e contexto de diagnóstico
worker_payment.tsConsumo: poison pill, retry por TTL, DLQ
dlq_payment.tsInspeção (x-death), alerta e replay ou descarte
idempotency_payment.tsClaim do id do pagamento no Redis
config_payment.tsLê e valida o ambiente no boot
dlq_payment.test.tstesteIntegração contra RabbitMQ e Redis reais: poison pill, retries, TTL, replay
demo.tsdemoPublica 5 pagamentos, espera a DLQ e drena