Dead-Letter Queue (DLQ)

A dead-letter queue (DLQ) is a separate queue where a message broker moves messages that failed processing too many times or expired. It parks the poison message for inspection instead of letting it block the main queue or loop forever.

Why it matters

Without a DLQ, a malformed message is retried indefinitely, wasting workers and delaying healthy messages behind it. With one, the main flow keeps moving and the failures are collected in a single place where you can alert, inspect and replay them after a fix.

A DLQ is also a monitoring signal. Its depth should normally be zero, so any growth means a bug, a downstream outage or bad input, and it deserves an alert.

Example

In Amazon SQS you attach a redrive policy to the source queue:

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789012:orders-dlq",
  "maxReceiveCount": 5
}

After a message has been received 5 times without being deleted, SQS moves it to orders-dlq. Other brokers such as RabbitMQ and Kafka-based setups offer the same idea through their own settings or conventions.

Common mistakes

• Creating a DLQ and never alerting on its depth, so failures pile up unseen.
• Letting messages expire from the DLQ before anyone looks. Check the retention period.
• Replaying everything blindly after a fix, which can repeat side effects if handlers are not idempotent.

Related

• Message queue
• RabbitMQ
• Idempotent
• Retry with backoff

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.