Dead-Letter Queue

Route a message to a separate holding queue after it exhausts its retry budget, instead of discarding it or blocking the main queue, so a poison message becomes a visible, inspectable, replayable artifact rather than a silent loss or a processing stall.

A message that permanently fails, or that exhausts a transient-failure retry budget, has nowhere to go: discarding it is a silent data loss, and retrying it forever blocks the queue or partition behind it and burns resources on a message that will never succeed.

A message fails when a consumer processes it. Some failures are transient (a brief downstream outage) and resolve on retry, per retry_with_backoff. Others are permanent: the message itself is malformed, references data that no longer exists, or triggers a bug in the handler. A permanently-failing message retried forever is a poison message: it blocks the partition or queue behind it (Kafka, ordered SQS FIFO) or consumes retry budget indefinitely (unordered queues) without ever succeeding.

A dead-letter queue (DLQ) is where a message goes once it exhausts its retry budget. This is not a passive trash bin: it is an active operational surface. Each broker implements the mechanics differently. SQS attaches a redrive policy to the source queue naming a target DLQ and a maxReceiveCount; once a message's receive count exceeds that threshold, SQS moves it automatically. RabbitMQ uses dead-letter exchanges: a queue's x-dead-letter-exchange argument routes rejected or expired messages to another exchange, from which a DLQ subscribes. Kafka has no broker-native DLQ; the convention is a consumer-managed dead-letter topic that the failing consumer explicitly produces to after exhausting its own retry logic, since Kafka's log-based model has no per-message negative-acknowledgment primitive to hook into.

Classifying a failure as permanent versus transient matters before dead-lettering it. A permanent failure (deserialization error, schema violation, a business rule the message can never satisfy) belongs in the DLQ immediately: retrying it wastes the retry budget on something that cannot succeed. A transient failure belongs in the DLQ only after retry_with_backoff's budget is exhausted, since retrying it first is exactly the case retry_with_backoff exists for. Routing every failure to the DLQ without this distinction turns retry policy into a formality and fills the DLQ with messages that would have succeeded on the next attempt.

A DLQ entry needs metadata beyond the original message: the original topic or queue, the failure reason and, where available, a stack trace or error code, the number of attempts made, and the timestamp of the first and last failure. Without this, an operator inspecting the DLQ cannot distinguish "reprocess this now, the downstream dependency is back" from "this message is permanently malformed, discard it after investigation."

A DLQ is not a complete error-handling strategy on its own. It converts silent loss into visible backlog, but a DLQ nobody monitors is functionally identical to discarding the message, just with extra storage cost and a false sense of safety. Reprocessing also has its own hazards: if the messages were originally ordered (a Kafka partition, an SQS FIFO queue), replaying them from the DLQ out of arrival order can violate ordering assumptions the original consumer relied on, and a bulk replay of a large DLQ can itself become a load spike or a stampede on the same downstream dependency that failed the first time.