sysdesign-dead-letter-queue

A dead-letter queue (DLQ) isolates failed messages by routing them out of the main queue for later inspection. This ensures transient or permanent failures do not block your consumer group and prevents data loss.

An effective retry policy uses exponential backoff with jitter to delay message reprocessing. Adding jitter prevents thundering retries and cascading system overloads during transient failure recovery in queue-based architectures.

You need a dead-letter queue when isolating messages that exhaust retry limits due to permanent failures. It separates toxic messages from the main stream, allowing your service to continue processing valid messages without disruption.

Reprocess DLQ messages using a reprocess-after-fix runbook that verifies the patch and moves messages back to the main queue. Safeguards for idempotency are required to prevent duplicate side effects during reprocessing.

Yes, the dead-letter queue strategy applies to queue- or stream-based architectures including RabbitMQ, Pub/Sub, SQS, and Kafka. It configures consumers to route failed messages to a dedicated DLQ per consumer group for isolation.

Growth alerting and retention on a dead-letter queue surface incidents without overwhelming dashboards. Alerting triggers when the DLQ grows, ensuring you remediate failures promptly, while retention manages storage lifecycle.