0x55aa
← Back to Blog

🏭 Job Queues in Node.js: Stop Making Your Users Wait for Slow Stuff

•5 min read
nodejsexpressbackendqueuesperformancebull

Picture this: a user hits "Sign Up" on your app. Your server receives the request, creates the account in the database, then sends a welcome email — blocking the response for 2 full seconds while your email provider's API does its thing. The user stares at a spinner. You stare at your 2-second p99 latency. Everyone is sad.

This is the job queue problem, and it haunts more production backends than anyone admits.

The "Why Are You Still Here?" Problem

Sending emails, resizing images, generating PDFs, syncing data to a third-party CRM, running ML inference — these are all tasks that don't need to happen before you respond to the user. They just need to happen eventually.

The fix is beautifully simple: accept the work, hand it off to a background worker, and immediately respond to the user. It's like a restaurant handing you a buzzer instead of making you stand at the pass while they cook.

That's a job queue.

HTTP Request → Enqueue Job → Respond "✓ Got it!"
                    ↓
             Background Worker → Do the Slow Thing

Meet Bull: The Node.js Queue You Actually Want to Use

Bull (or its newer sibling BullMQ) sits on top of Redis and gives you a production-grade queue in about 20 lines of code. Install it:

npm install bull
# You'll need Redis running — docker run -p 6379:6379 redis works fine locally

Here's a real example: sending welcome emails without blocking your signup endpoint.

// queues/emailQueue.js
const Bull = require('bull');

const emailQueue = new Bull('email', {
  redis: { host: '127.0.0.1', port: 6379 },
});

// Define the worker — this runs in the background
emailQueue.process(async (job) => {
  const { to, subject, body } = job.data;
  console.log(`Sending email to ${to}...`);

  // Your actual email sending logic (nodemailer, SendGrid, etc.)
  await sendEmail({ to, subject, body });

  console.log(`Email sent to ${to} ✓`);
});

module.exports = emailQueue;

// routes/auth.js
const express = require('express');
const emailQueue = require('../queues/emailQueue');
const router = express.Router();

router.post('/signup', async (req, res) => {
  const { email, name } = req.body;

  // 1. Create the user (fast)
  const user = await User.create({ email, name });

  // 2. Enqueue the email (instant — just writes to Redis)
  await emailQueue.add({
    to: email,
    subject: 'Welcome aboard! 🎉',
    body: `Hey ${name}, glad to have you here.`,
  });

  // 3. Respond immediately — no waiting for email delivery
  res.status(201).json({ message: 'Account created!', userId: user.id });
});

Your endpoint now responds in milliseconds. The email goes out a second or two later. The user never notices the difference — they're already exploring your app.

The Three Things That Make Queues Actually Production-Ready

1. Retries (Because the Internet is a Liar)

External APIs fail. Networks hiccup. Your email provider has a 3am outage. Bull handles this gracefully:

await emailQueue.add(jobData, {
  attempts: 3,           // Retry up to 3 times
  backoff: {
    type: 'exponential', // Wait longer between each retry
    delay: 2000,         // Start at 2s, then 4s, then 8s
  },
});

Without retries, a single transient failure means a lost email. With retries, it's a self-healing system.

2. Job Priorities

Not all background work is equal. A password-reset email is urgent. A "monthly digest" newsletter can wait. Bull lets you set priorities (lower number = higher priority):

// Urgent — process first
await emailQueue.add(resetPasswordData, { priority: 1 });

// Can wait
await emailQueue.add(weeklyDigestData, { priority: 10 });

3. Delayed Jobs (Scheduled Work Without a Cron Job)

Want to send a follow-up email 24 hours after signup if the user hasn't activated their account? No cron needed:

await emailQueue.add(
  { to: email, subject: 'Did you forget about us? 👀' },
  { delay: 24 * 60 * 60 * 1000 } // 24 hours in ms
);

The job sits in Redis, dormant, until it's time. This is enormously useful for drip campaigns, reminders, and trial expiry nudges.

A Common Gotcha: Running Workers Separately

Here's a mistake I've seen in the wild: defining queue processors in the same process as your Express app and then wondering why the app slows down under load.

In production, run your workers as separate processes:

Process 1: node server.js      ← Express, handles HTTP
Process 2: node worker.js      ← Bull, processes jobs
Process 3: node worker.js      ← Scale workers horizontally as needed

Your worker.js just imports the queue and registers processors:

// worker.js
require('./queues/emailQueue');
require('./queues/imageQueue');
require('./queues/pdfQueue');
console.log('Workers started, waiting for jobs...');

Now your web server stays snappy regardless of how many background jobs are running. Each layer scales independently.

The Bigger Picture: What Else Goes in a Queue?

Once you have the pattern, you'll start seeing queues everywhere:

  • Image/video processing — Upload the file, respond immediately, resize/transcode in the background
  • PDF generation — Trigger it, let the user know it'll be ready in their dashboard
  • Webhook delivery — Don't let a slow third-party endpoint hold up your response
  • Search index updates — Write to your DB, queue the Elasticsearch sync separately
  • Audit logging — Fire-and-forget log writes that shouldn't affect request latency

The rule of thumb: if it's slow, fallible, or doesn't need to block the response — queue it.

Wrapping Up

Job queues are one of those backend patterns that seem complicated until you try them, and then you wonder how you ever lived without them. Bull + Redis gives you retry logic, priorities, delays, and monitoring (check out Bull Board for a UI) with minimal setup.

Your users get instant responses. Your slow operations happen reliably in the background. Your latency graphs look great. Everyone wins.

Ready to offload your slow stuff? Grab Bull, spin up a Redis container, and queue your first job this afternoon. Start with email — it's the perfect low-stakes experiment. Then watch your response times drop and quietly feel very smug about it.

What slow operations are you still doing synchronously? Time to set them free. 🚀

← Back to all posts