Queues Basics

Q: Redis required for queues?

BullMQ requires Redis. AWS SQS is alternative - see AWS SQS Consumers.

Q: How fast should HTTP return after enqueue?

Sub-50ms p95. Enqueue is one Redis round trip.

Q: What if worker is down?

Jobs accumulate in queue. Alert on depth; scale workers or fix consumer.

Q: Exactly-once delivery?

No. Aim at-least-once with idempotent workers.

Q: NestJS queues?

@nestjs/bullmq wraps BullMQ modules. Same retry and idempotency rules.

Q: Priority queues?

BullMQ supports priority numbers. Use sparingly - starves low priority if abused.

Q: Delayed jobs?

delay: 60000 for scheduled send. Repeatable for cron patterns.

Q: Big payloads?

Store blob in S3; queue only reference id. Redis job payload stays small.

8 examples to get you started with queues and workers for Node.js - 6 basic and 2 intermediate.

Prerequisites

npm install bullmq ioredis
npm install -D typescript@5.6 tsx

Redis 7 required for BullMQ. See BullMQ for production worker setup.

Basic Examples

1. Why Queue?

In HTTP request	In worker
Send email	OK
Resize 50 images	Queue
Charge card + fulfill	Queue after idempotency key
Return search results <100ms	Sync DB only

Users perceive latency from slowest work in the request path
Workers retry without user waiting on socket timeout

Related: BullMQ - Redis-backed queues

2. Producer Enqueues Job (Express 5)

import { Queue } from "bullmq";
import IORedis from "ioredis";
 
const connection = new IORedis(process.env.REDIS_URL!, { maxRetriesPerRequest: null });
const emailQueue = new Queue("email", { connection });
 
app.post("/invite", async (req, res) => {
  const job = await emailQueue.add("send-invite", {
    to: req.body.email,
    orgId: req.body.orgId,
  });
  res.status(202).json({ jobId: job.id });
});

202 Accepted signals async processing
Job payload should be JSON-serializable and small
Include correlation id for tracing

3. Worker Consumes Job

import { Worker } from "bullmq";
import IORedis from "ioredis";
 
const connection = new IORedis(process.env.REDIS_URL!, { maxRetriesPerRequest: null });
 
new Worker(
  "email",
  async (job) => {
    if (job.name === "send-invite") {
      await sendInviteEmail(job.data.to, job.data.orgId);
    }
  },
  { connection, concurrency: 5 }
);

Run workers as separate process or container from API
concurrency bounds parallel jobs per worker pod
Throwing error triggers BullMQ retry policy

4. Retry and Backoff

await emailQueue.add(
  "send-invite",
  { to, orgId },
  {
    attempts: 5,
    backoff: { type: "exponential", delay: 2000 },
    removeOnComplete: 1000,
    removeOnFail: false,
  }
);

Exponential backoff reduces thundering herd on vendor outage
Keep failed jobs for DLQ inspection (removeOnFail: false)
Cap attempts so poison messages eventually stop

Related: Retries with Backoff

5. Job Status Endpoint

app.get("/jobs/:id", async (req, res) => {
  const job = await emailQueue.getJob(req.params.id);
  if (!job) return res.status(404).json({ error: "not_found" });
  const state = await job.getState();
  res.json({ id: job.id, state, progress: job.progress });
});

States: waiting, active, completed, failed, delayed
Poll or use SSE/WebSocket for UI progress
Do not expose internal stack traces in job API

6. Idempotency Before Side Effects

await paymentsQueue.add("capture", { paymentId, idempotencyKey }, { jobId: idempotencyKey });

Stable jobId dedupes duplicate enqueue from client retries
Worker still checks DB unique constraint before charging
See Idempotency Keys

Intermediate Examples

7. Separate Deployables

api/          -> HTTP + enqueue only
worker-email/ -> BullMQ Worker
worker-media/ -> heavy CPU queue

API scales on RPS; workers scale on queue depth
Different resource limits (CPU for image worker)
Shared Redis and Postgres URLs via env

Related: Reference Worker Fleet

8. Queue vs Cron

Trigger	Tool
User action	Queue job now
Every night 2am	Cron + optional leader lock
Every 5 minutes	BullMQ repeatable job

Cron without leader lock runs duplicate on N pods
See Scheduling & Cron

FAQs

Redis required for queues?

BullMQ requires Redis. AWS SQS is alternative - see AWS SQS Consumers.

How fast should HTTP return after enqueue?

Sub-50ms p95. Enqueue is one Redis round trip.

What if worker is down?

Jobs accumulate in queue. Alert on depth; scale workers or fix consumer.

Exactly-once delivery?

No. Aim at-least-once with idempotent workers.

NestJS queues?

@nestjs/bullmq wraps BullMQ modules. Same retry and idempotency rules.

Priority queues?

BullMQ supports priority numbers. Use sparingly - starves low priority if abused.

Delayed jobs?

delay: 60000 for scheduled send. Repeatable for cron patterns.

Big payloads?

Store blob in S3; queue only reference id. Redis job payload stays small.

BullMQ - production patterns
AWS SQS Consumers - managed queue
Idempotency Keys - safe retries
Queues Best Practices - monitoring checklist
Graceful Shutdown - drain workers

Node.js Official Website - Homepage, downloads, releases, and news.
Node.js Best Practices (GitHub) - Curated production best practices.
DigitalOcean Node.js Tutorials - Production-oriented how-tos.
Distributed Systems with Node.js - Enterprise-ready distributed systems.
Node.js Design Patterns, 4th Edition - Production-grade application patterns.

Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.

Prerequisites

npm install bullmq ioredis
npm install -D typescript@5.6 tsx

Redis 7 required for BullMQ. See BullMQ for production worker setup.

Basic Examples

1. Why Queue?

In HTTP request	In worker
Send email	OK
Resize 50 images	Queue
Charge card + fulfill	Queue after idempotency key
Return search results <100ms	Sync DB only

Users perceive latency from slowest work in the request path
Workers retry without user waiting on socket timeout

Related: BullMQ - Redis-backed queues

2. Producer Enqueues Job (Express 5)

import { Queue } from "bullmq";
import IORedis from "ioredis";
 
const connection = new IORedis(process.env.REDIS_URL!, { maxRetriesPerRequest: null });
const emailQueue = new Queue("email", { connection });
 
app.post("/invite", async (req, res) => {
  const job = await emailQueue.add("send-invite", {
    to: req.body.email,
    orgId: req.body.orgId,
  });
  res.status(202).json({ jobId: job.id });
});

202 Accepted signals async processing
Job payload should be JSON-serializable and small
Include correlation id for tracing

3. Worker Consumes Job

import { Worker } from "bullmq";
import IORedis from "ioredis";
 
const connection = new IORedis(process.env.REDIS_URL!, { maxRetriesPerRequest: null });
 
new Worker(
  "email",
  async (job) => {
    if (job.name === "send-invite") {
      await sendInviteEmail(job.data.to, job.data.orgId);
    }
  },
  { connection, concurrency: 5 }
);

Run workers as separate process or container from API
concurrency bounds parallel jobs per worker pod
Throwing error triggers BullMQ retry policy

4. Retry and Backoff

await emailQueue.add(
  "send-invite",
  { to, orgId },
  {
    attempts: 5,
    backoff: { type: "exponential", delay: 2000 },
    removeOnComplete: 1000,
    removeOnFail: false,
  }
);

Exponential backoff reduces thundering herd on vendor outage
Keep failed jobs for DLQ inspection (removeOnFail: false)
Cap attempts so poison messages eventually stop

Related: Retries with Backoff

5. Job Status Endpoint

app.get("/jobs/:id", async (req, res) => {
  const job = await emailQueue.getJob(req.params.id);
  if (!job) return res.status(404).json({ error: "not_found" });
  const state = await job.getState();
  res.json({ id: job.id, state, progress: job.progress });
});

States: waiting, active, completed, failed, delayed
Poll or use SSE/WebSocket for UI progress
Do not expose internal stack traces in job API

6. Idempotency Before Side Effects

await paymentsQueue.add("capture", { paymentId, idempotencyKey }, { jobId: idempotencyKey });

Stable jobId dedupes duplicate enqueue from client retries
Worker still checks DB unique constraint before charging
See Idempotency Keys

Intermediate Examples

7. Separate Deployables

api/          -> HTTP + enqueue only
worker-email/ -> BullMQ Worker
worker-media/ -> heavy CPU queue

API scales on RPS; workers scale on queue depth
Different resource limits (CPU for image worker)
Shared Redis and Postgres URLs via env

Related: Reference Worker Fleet

8. Queue vs Cron

Trigger	Tool
User action	Queue job now
Every night 2am	Cron + optional leader lock
Every 5 minutes	BullMQ repeatable job

Cron without leader lock runs duplicate on N pods
See Scheduling & Cron

FAQs

Redis required for queues?

BullMQ requires Redis. AWS SQS is alternative - see AWS SQS Consumers.

How fast should HTTP return after enqueue?

Sub-50ms p95. Enqueue is one Redis round trip.

What if worker is down?

Jobs accumulate in queue. Alert on depth; scale workers or fix consumer.

Exactly-once delivery?

No. Aim at-least-once with idempotent workers.

NestJS queues?

@nestjs/bullmq wraps BullMQ modules. Same retry and idempotency rules.

Priority queues?

BullMQ supports priority numbers. Use sparingly - starves low priority if abused.

Delayed jobs?

delay: 60000 for scheduled send. Repeatable for cron patterns.

Big payloads?

Store blob in S3; queue only reference id. Redis job payload stays small.

BullMQ - production patterns
AWS SQS Consumers - managed queue
Idempotency Keys - safe retries
Queues Best Practices - monitoring checklist
Graceful Shutdown - drain workers

Node.js Official Website - Homepage, downloads, releases, and news.
Node.js Best Practices (GitHub) - Curated production best practices.
DigitalOcean Node.js Tutorials - Production-oriented how-tos.
Distributed Systems with Node.js - Enterprise-ready distributed systems.
Node.js Design Patterns, 4th Edition - Production-grade application patterns.

Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.

Queues Basics

Search Documentation

Queues Basics