All 15 Background Jobs & Queues questions
More in Background Jobs & Queues
What is job concurrency in a worker process, and how do you configure it safely in BullMQ? How would you track and expose the progress of a long-running background job to the client that requested it? What are the trade-offs of using an in-memory job queue (like a simple array-based queue) versus a persistent, Redis-backed queue? What is a 'stalled' job in BullMQ, and what causes it? How do you implement job prioritization in a Node.js queue system, and when is it necessary? What is the difference between a message queue (like RabbitMQ) and a job queue (like BullMQ), and when would you choose one over the other? How do you implement graceful shutdown for a Node.js background worker process to avoid losing or corrupting in-progress jobs? What is job de-duplication in a queue system, and how would you prevent the same logical job from being enqueued multiple times? How do you implement rate-limited job processing so a Node.js worker doesn't exceed a downstream third-party API's request limits?
Advertisement
Back to results for “Error Handling”
Node.js › Background Jobs & Queues

What is a dead-letter queue (DLQ), and how should a Node.js job-processing system use one?

Advanced

Answer

A dead-letter queue holds jobs that have permanently failed after exhausting all configured retry attempts, rather than discarding them silently -- this preserves the failed job's data and error context for manual inspection, alerting, or later reprocessing once a root cause is fixed, preventing 'silent data loss' where a systematically failing job type (due to a bug or a bad input) would otherwise just vanish after its retries ran out.
const worker = new Worker('orders', processOrder, {
  connection,
  settings: { maxStalledCount: 3 },
});

worker.on('failed', async (job, err) => {
  if (job.attemptsMade >= job.opts.attempts) {
    await deadLetterQueue.add('failed-order', { originalJob: job.data, error: err.message });
    await alertOncall(`Job ${job.id} moved to DLQ: ${err.message}`);
  }
});
Real-world example An order-fulfillment system routes any order job that fails all five retry attempts into a dead-letter queue and triggers a Slack alert to the on-call engineer, who can inspect the specific failure reason and either fix a data issue and manually replay the job, or confirm it should be permanently discarded.

Common follow-ups: How do you decide an appropriate number of retries before a job should be considered permanently failed and moved to the DLQ?;What operational tooling or dashboard would you build around monitoring and reprocessing a dead-letter queue?

Error Handling;Logging & Monitoring
All 15 Background Jobs & Queues questions