Dead letter queue (DLQ) to kolejka dla wiadomości / jobs które wielokrotnie nie powiodły się w processing. Zamiast tracić failed items po N retry — lądują w DLQ do manualnej inspekcji.
Klasyczny pattern:
- Job lands w main queue
- Worker próbuje processing
- Fail? Retry z exponential backoff (1s, 2s, 4s, 8s...)
- Po 5-10 failed attempts → przesuń do DLQ
- DLQ ma alert (Slack, email) i UI do inspekcji
- Engineer reviewuje failed jobs, fixuje root cause, replay z DLQ → main queue
Co tam ląduje w praktyce:
- Permanent failures (404, malformed data, banned account)
- Schema drift (target API zmienił format)
- Network outages dłuższe niż retry budget
- Software bugs które wyszły dopiero w produkcji
Bez DLQ: failed jobs są tracone milcząco. Customer dzwoni "gdzie mój raport?" — i okazuje się że pipeline failuje od 3 dni a nikt nie zauważył. Z DLQ: wszystko jest widoczne, recoverable, audytowalne.
Implementacja: RabbitMQ ma built-in DLX (Dead Letter Exchange). AWS SQS ma redrive policy. Redis Streams + manual logic. PostgreSQL z status column. Patrz nasza zasada engineeringu "Dead-letter everything".