All 15 Background Jobs & Queues questions
More in Background Jobs & Queues
What is a background job in the context of a Node.js web application, and why can't long-running work simply happen inside a request handler? What is the difference between a delayed job and a scheduled (repeatable) job in a Node.js job queue? How does BullMQ (built on Redis) implement a job queue in Node.js, and what are its core building blocks? What is a cron job, and how would you schedule recurring background tasks in a Node.js application using node-cron or BullMQ's repeatable jobs? 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? What is a dead-letter queue (DLQ), and how should a Node.js job-processing system use one? How do you implement job prioritization in a Node.js queue system, and when is it necessary?
Advertisement
Back to results for “Error Handling”
Node.js › Background Jobs & Queues

What is job idempotency, and why is it critical when designing background job processing?

Intermediate

Answer

A job is idempotent if running it more than once produces the same end result as running it exactly once -- this matters because most queue systems provide 'at-least-once' delivery guarantees (a job might be redelivered and processed twice if a worker crashes after completing the work but before acknowledging it), so jobs that aren't idempotent (like 'charge the customer $50' run naively) can cause serious bugs like double-charging if ever retried or redelivered.
// Non-idempotent: retrying this job double-charges the customer
async function chargeCustomer(job) { await paymentGateway.charge(job.data.amount); }

// Idempotent: uses a unique idempotency key so a retry is a no-op
async function chargeCustomer(job) {
  await paymentGateway.charge(job.data.amount, { idempotencyKey: job.data.orderId });
}
Real-world example A payment-processing worker includes the order ID as an idempotency key on every charge request sent to the payment gateway, so that if the same job is accidentally processed twice due to a worker crash and retry, the gateway itself recognizes the duplicate request and returns the original charge result instead of billing the customer again.

Common follow-ups: How do you make a database-write job idempotent when the underlying operation isn't naturally idempotent?;What queue-level guarantees (at-most-once vs at-least-once vs exactly-once) does your specific queue technology actually provide?

Databases & ORMs (MongoDB/Mongoose SQL/Sequelize);Error Handling
All 15 Background Jobs & Queues questions