Dead Letter Queues: What They Are, When to Use Them, and How to Set Them Up

Every message queue eventually receives a message it can’t process. Maybe the payload is malformed. Maybe a downstream service is broken. Maybe the code has a bug that keeps throwing an exception for one specific order ID.

What happens to that message is what separates a resilient system from a ticking clock.

Without a safety net, that message either retries forever — blocking throughput and burning resources — or it gets silently discarded and you never know it existed. Neither outcome is acceptable when the message represents real business data.

Dead Letter Queues are that safety net.

What Is a Dead Letter Queue?

A Dead Letter Queue (DLQ) is a separate queue where messages go after they’ve failed to be processed successfully. Think of it as a quarantine zone, not a trash can. The message isn’t gone — it’s isolated, preserved, and waiting for you to investigate.

Messages end up in a DLQ for a handful of reasons:

Retry limit exceeded — the consumer tried N times and kept failing
TTL expired — the message sat in the queue longer than its allowed lifetime
Queue is full — the main queue hit its length limit and had to reject new arrivals
Explicit rejection — the consumer processed the message but decided it was unprocessable and rejected it without requeue

The key distinction: a DLQ doesn’t mean “garbage.” It means “something went wrong here and we need to know about it.”

When Should You Use One?

Use a DLQ any time you’re processing messages that matter. That’s a broad answer, so here’s what it looks like in practice:

Use a DLQ when: – Your service processes orders, payments, notifications, or anything where a lost message has real consequences – You need an audit trail of what failed and why – You want to prevent a single bad message from blocking the entire queue – You’re running any async event-driven architecture with multiple consumers

Don’t use a DLQ as: – A substitute for fixing broken consumers — if messages pile up, that’s a symptom, not a solution – A long-term storage system for failed messages — DLQs need active monitoring and a replay process – An excuse to skip input validation — validate at the edge, before messages even enter the queue

How It Works: Code Examples

Node.js — RabbitMQ (amqplib)

const amqp = require('amqplib');

async function setup() {
  const conn = await amqp.connect('amqp://localhost');
  const channel = await conn.createChannel();

  // 1. Create the dead letter exchange and DLQ
  await channel.assertExchange('orders.dlx', 'direct', { durable: true });
  await channel.assertQueue('orders.dlq', { durable: true });
  await channel.bindQueue('orders.dlq', 'orders.dlx', 'orders');

  // 2. Create the main queue — point failed messages at the DLX
  await channel.assertQueue('orders', {
    durable: true,
    arguments: {
      'x-dead-letter-exchange': 'orders.dlx',
      'x-dead-letter-routing-key': 'orders',
      'x-message-ttl': 60000        // messages expire after 60 seconds
    }
  });

  // 3. Consumer — nack with requeue=false to dead-letter permanently
  channel.consume('orders', async (msg) => {
    try {
      await processOrder(JSON.parse(msg.content.toString()));
      channel.ack(msg);
    } catch (err) {
      console.error('Processing failed:', err.message);

      const retryCount = (msg.properties.headers['x-retry-count'] || 0);
      if (retryCount >= 3 || isPermanentError(err)) {
        // Send to DLQ — no requeue
        channel.nack(msg, false, false);
      } else {
        // Retry — requeue
        channel.nack(msg, false, true);
      }
    }
  });

  // 4. DLQ consumer — inspect what's failing
  channel.consume('orders.dlq', async (msg) => {
    const failed = JSON.parse(msg.content.toString());
    console.error('Dead-lettered message:', failed);
    await alertOpsTeam({ message: failed, headers: msg.properties.headers });
    channel.ack(msg);
  });
}

Node.js — AWS SQS

const { SQSClient, CreateQueueCommand, SendMessageCommand,
        ReceiveMessageCommand, DeleteMessageCommand } = require('@aws-sdk/client-sqs');

const sqs = new SQSClient({ region: 'us-east-1' });

// 1. Create the DLQ first
const dlq = await sqs.send(new CreateQueueCommand({
  QueueName: 'orders-dlq',
  Attributes: { MessageRetentionPeriod: '604800' }  // 7 days
}));

// Get the DLQ ARN (needed for the redrive policy)
const dlqArn = 'arn:aws:sqs:us-east-1:123456789:orders-dlq';

// 2. Create the main queue with a redrive policy
const main = await sqs.send(new CreateQueueCommand({
  QueueName: 'orders',
  Attributes: {
    RedrivePolicy: JSON.stringify({
      deadLetterTargetArn: dlqArn,
      maxReceiveCount: '3'    // Move to DLQ after 3 failed receives
    })
  }
}));

// SQS handles dead-lettering automatically — no consumer code changes needed

.NET C# — MassTransit (RabbitMQ)

// Register MassTransit with automatic retry + dead-letter handling
services.AddMassTransit(x =>
{
    x.AddConsumer<OrderConsumer>();

    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.ReceiveEndpoint("orders", e =>
        {
            // Retry 3 times with 5-second intervals before dead-lettering
            e.UseMessageRetry(r => r.Interval(3, TimeSpan.FromSeconds(5)));

            // Configure dead letter exchange
            e.DeadLetterExchange = "orders.dlx";

            e.ConfigureConsumer<OrderConsumer>(ctx);
        });
    });
});

// Consumer — throwing an exception after retries are exhausted dead-letters the message
public class OrderConsumer : IConsumer<OrderCreated>
{
    public async Task Consume(ConsumeContext<OrderCreated> context)
    {
        var order = context.Message;

        // Validate first — reject permanently without retrying
        if (!IsValid(order))
            throw new InvalidOperationException($"Invalid order payload: {order.Id}");

        await ProcessOrderAsync(order);
    }
}

.NET C# — AWS SQS (AWSSDK)

public class SqsOrderProcessor : BackgroundService
{
    private readonly IAmazonSQS _sqs;
    private readonly string _queueUrl;

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        while (!ct.IsCancellationRequested)
        {
            var response = await _sqs.ReceiveMessageAsync(new ReceiveMessageRequest
            {
                QueueUrl = _queueUrl,
                MaxNumberOfMessages = 10,
                WaitTimeSeconds = 20
            }, ct);

            foreach (var msg in response.Messages)
            {
                try
                {
                    var order = JsonSerializer.Deserialize<Order>(msg.Body);
                    await ProcessOrderAsync(order);

                    // Success — delete from queue
                    await _sqs.DeleteMessageAsync(_queueUrl, msg.ReceiptHandle, ct);
                }
                catch (Exception ex)
                {
                    // Don't delete — SQS increments the receive count.
                    // After maxReceiveCount failures, SQS moves it to the DLQ automatically.
                    _logger.LogError(ex, "Failed to process message {MessageId}", msg.MessageId);
                }
            }
        }
    }
}

What To Do With Dead-Lettered Messages

Having a DLQ is only half the job. You need a plan for what happens when messages land in it.

Monitor it. Set up an alert on DLQ depth. A growing DLQ means something is systematically broken, and you want to know within minutes, not days.

Inspect the failures. Look at the message payload and the headers. RabbitMQ adds x-death headers with the reason, original queue, and timestamp. AWS SQS preserves the original message body. The clue you need is usually right there.

Fix the root cause. A DLQ is a diagnostic tool. If the same message type keeps failing, that’s a code bug or a schema mismatch — fix it.

Replay valid messages. Once you’ve fixed the issue, replay the messages back into the main queue. Most platforms support this natively: AWS SQS has “Start DLQ redrive,” RabbitMQ lets you shovel messages back. Don’t replay blindly — validate the messages are still relevant first.

Archive the rest. Messages that genuinely can’t be processed (like records for deleted accounts) should be archived or discarded intentionally, not silently.

Common Mistakes

Not monitoring the DLQ. By far the most common mistake. The DLQ fills up and nobody notices for weeks. If a tree falls in the forest and no one set up an alert, did the order fail?

Setting maxReceiveCount too high. Three to five retries is usually right. Setting it to 50 means a broken message spends hours in your system before landing in the DLQ. That’s wasted compute and delayed diagnosis.

Never replaying DLQ messages. The whole point is recoverability. If you archive everything without ever investigating, you’re not running a resilient system — you’re running a slow data sink.

Using the DLQ as a bandage. If your DLQ is filling up every day, that’s not a DLQ problem. That’s a consumer bug, a schema drift, or a missing validation step. The DLQ is telling you something. Listen to it.