Dead Letter Queue
A dead letter queue (DLQ) is a secondary queue used in messaging systems to store messages that cannot be successfully processed or delivered by the primary system. These messages are often referred to as "dead letters" because the main system has given up on them, typically after repeated failures caused by unresponsive consumers, malformed messages, or invalid routing.
The purpose of a DLQ is simple: failure should not mean data loss. Instead of discarding a message that keeps failing, the system parks it somewhere durable where it can be inspected, fixed, and replayed.
How a dead letter queue works
A DLQ sits at the end of a retry pipeline. When a message fails, the system retries it, usually on an exponential backoff schedule. Only after the retry budget is exhausted does the message move to the dead letter queue, along with metadata about why it failed and how many attempts were made. From there, an operator or an automated process can examine the dead letters, fix the underlying problem, and re-drive the messages through the main pipeline.
Most messaging infrastructure has the concept built in. SQS lets you attach a dead-letter queue to any queue with a maximum receive count, RabbitMQ routes rejected or expired messages to a dead-letter exchange, and Kafka pipelines conventionally publish failing records to a separate dead-letter topic. The mechanics differ, but the contract is the same: the main queue stays healthy, and failures accumulate somewhere you can deal with them on your own schedule.
Dead letter queues in webhook systems
In [webhook services]https://www.svix.com/?utm_source=resources&utm_medium=content), dead letter queues improve reliability and fault tolerance on both sides of the delivery.
On the sending side, when a webhook is delivered to a subscriber's endpoint and the subscriber fails to acknowledge it through every retry, the message lands in a DLQ instead of vanishing. This allows the webhook provider to track which messages failed, alert the subscriber, and replay the messages once the broken endpoint is fixed, which matters because the alternative is customers silently missing events.
On the receiving side, endpoints that enqueue incoming webhooks for background processing should give that internal queue a DLQ too. A malformed payload or a bug in the handler will otherwise either poison the queue, blocking everything behind it, or get dropped entirely.
Dead letter queues help ensure that important event information is not lost due to temporary failures, making them a standard component of a resilient webhook architecture. For a deeper treatment, including how to size retry budgets and when to alert on DLQ depth, see our guide on dead letter queues in webhook systems.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis