Dead Letter Queue

A dead letter queue (DLQ) is a separate queue that receives messages a system could not deliver or process, so that they can be inspected rather than silently discarded or retried forever. Amazon SQS describes a dead-letter queue as a target for messages that are not processed successfully, useful because it isolates unconsumed messages so you can determine why processing did not succeed. Azure Service Bus implements the same idea as a secondary sub-queue that exists automatically for every queue and subscription. Details below follow vendor documentation checked in September 2026.

How a message ends up there

• Too many failed attempts. SQS uses a redrive policy whose maxReceiveCount sets how many times a consumer may receive a message before it is moved; the documentation warns that a low value such as 1 sends a message to the DLQ after a single failure, and advises setting it high enough to allow sufficient retries. Service Bus increments a delivery count whenever a message under peek-lock is abandoned or its lock expires, and moves it at a default limit of 10 with the reason MaxDeliveryCountExceeded.
• Expiry. With dead-lettering enabled, Service Bus moves expiring messages to the DLQ with the reason TTLExpiredException.
• Message-level problems. Service Bus also dead-letters for oversized headers, a missing session ID on a session-enabled entity, and exceeding the forwarding hop limit.
• An explicit decision by the application. A consumer that receives a malformed payload can dead-letter it deliberately. Service Bus’s documentation recommends recording the exception type and stack trace in the dead-letter reason and description, which is what makes the queue diagnosable later.

What it obliges you to do

A DLQ converts an immediate failure into a deferred one. That is a real gain — the consumer stops retrying a poison message and the rest of the queue keeps moving — but the deferred failure is still a failure, and it is now somewhere nobody is looking by default.

• Alarm on depth, not just on errors. AWS documents configuring a CloudWatch alarm for any messages moved to a dead-letter queue. Any non-zero depth is a fact someone should know within the hour, not at quarter end.
• Watch the retention arithmetic. For SQS standard queues, expiry is based on the original enqueue timestamp, which does not change when the message moves — so a message that spent a day in the source queue is deleted after three days in a DLQ whose retention is four. The documented best practice is to set the DLQ’s retention longer than the source queue’s. Service Bus takes the other approach: TTL is not observed in the DLQ and there is no automatic cleanup, so messages stay until someone retrieves and completes them.
• Plan the way back. SQS provides dead-letter queue redrive to move messages out again; Service Bus messages can be resubmitted after the underlying issue is fixed. Redelivery means the record may be applied twice, so the destination write has to be idempotent before a bulk resubmission is safe.
• Mind ordering. AWS advises against using a dead-letter queue with a FIFO queue where breaking the exact order of messages or operations would change their meaning.

In a data pipeline

The same pattern appears outside message brokers: rejected rows written to an error table, files that failed parsing moved to a rejects folder, records that failed validation set aside instead of loaded. Whatever it is called, the operational questions are identical — who is alerted, how the cause is classified, how the corrected records are reintroduced, and whether totals reported in the meantime are known to be short by that amount. Holding the records for examination rather than dropping them is the data quarantine idea applied to messaging.

The failure mode worth naming: a dead letter queue nobody reads is indistinguishable from data loss, with the added disadvantage that everyone believes the data is safe. How this fits with duplicates, loss, and reconciliation across a pipeline is worked through in The Job Succeeded and the Numbers Are Wrong.

References: Amazon SQS Developer Guide, Using dead-letter queues in Amazon SQS; Microsoft Learn, Service Bus dead-letter queues.