0x55aa
← Back to Blog

⚡ Node.js Worker Threads: CPU-Intensive Tasks Without Blocking Your Entire App

•6 min read
"nodejs""backend""performance""concurrency""express"

⚡ Node.js Worker Threads: CPU-Intensive Tasks Without Blocking Your Entire App

If you've used Node.js for more than five minutes, someone has probably warned you about blocking the event loop. "Don't run CPU-intensive code in Node.js!" they cry, clutching their async/await like a security blanket. And for a long time, they were right — doing heavy computation in Node.js was like trying to do math homework while also being a waiter. One customer asks for the specials, and the entire restaurant grinds to a halt.

But Node.js 12+ has a solution that most developers still haven't heard of: Worker Threads.

The Problem: One Thread, One Traffic Jam

Node.js runs on a single thread. This is great for I/O-heavy work (waiting for database queries, HTTP calls, file reads) because the event loop can juggle thousands of concurrent operations without breaking a sweat. The event loop doesn't block while waiting — it just moves on.

But CPU-bound work is a different beast. Tasks like image processing, parsing a 500,000-row CSV, complex data transformation, or cryptographic operations don't involve waiting. They just compute. And while they're computing, the event loop is stuck. Every other request coming into your Express server sits in a queue, tapping its foot, wondering why the checkout page is taking 8 seconds.

// This blocks your ENTIRE server while it runs
app.get('/generate-report', (req, res) => {
  const result = processHugeDataset(req.query.data); // 😬 blocking for 3 seconds
  res.json({ result });
});

While processHugeDataset grinds away, every other request to your app — healthchecks, login endpoints, anything — is dead in the water. Your monitoring alerts. Your users bounce. Your boss messages you on Slack at 11pm. We've all been there.

Enter Worker Threads

Worker Threads let you spawn actual OS threads that run JavaScript code in parallel. Unlike child_process.fork() (which creates a whole new Node.js process with its own memory and startup cost), Worker Threads share memory with the main thread and communicate via structured message passing.

It's the difference between hiring a contractor (a new process) and actually cloning yourself (a thread). The clone doesn't need its own office, its own computer, or a 30-second startup time. It just gets to work.

Here's the pattern:

// worker.js — this runs in a separate thread
const { workerData, parentPort } = require('worker_threads');

function processHugeDataset(data) {
  // Simulate CPU-intensive work
  let result = 0;
  for (let i = 0; i < data.rows; i++) {
    result += Math.sqrt(i) * data.multiplier;
  }
  return result;
}

const result = processHugeDataset(workerData);
parentPort.postMessage({ result });

// main.js — your Express route, now non-blocking
const { Worker } = require('worker_threads');
const path = require('path');

function runInWorker(data) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(path.resolve(__dirname, './worker.js'), {
      workerData: data,
    });

    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`));
    });
  });
}

app.get('/generate-report', async (req, res) => {
  // Heavy work runs in a thread — event loop stays free
  const { result } = await runInWorker({
    rows: 1_000_000,
    multiplier: parseFloat(req.query.factor ?? '1'),
  });
  res.json({ result });
});

The main thread stays free. The worker does the crunching, fires a message back when done, and your route handler resolves the promise. Other requests sail through while the computation runs. It's the same pattern as offloading to a queue — but synchronous, in-process, and without Redis.

Don't Spawn a New Worker Per Request

One critical gotcha: creating a new Worker instance for every incoming request is expensive. Thread creation has overhead, and under load you'd spawn hundreds of threads. Your server would have a very bad time.

The correct pattern is a worker pool — a fixed number of reusable workers:

// worker-pool.js
const { Worker } = require('worker_threads');
const os = require('os');

class WorkerPool {
  constructor(workerFile, size = os.cpus().length - 1) {
    this.queue = [];
    this.workers = Array.from({ length: size }, () => ({
      worker: new Worker(workerFile),
      idle: true,
    }));

    this.workers.forEach(({ worker }) => {
      worker.on('message', (msg) => {
        const entry = this.workers.find((w) => w.worker === worker);
        if (entry) entry.idle = true;

        const task = this.queue.shift();
        if (task) {
          this._assign(entry, task);
        } else {
          const pending = this.pending?.get(worker);
          if (pending) {
            pending.resolve(msg);
            this.pending.delete(worker);
          }
        }
      });

      worker.on('error', (err) => {
        const pending = this.pending?.get(worker);
        if (pending) pending.reject(err);
      });
    });

    this.pending = new Map();
  }

  run(data) {
    return new Promise((resolve, reject) => {
      const idle = this.workers.find((w) => w.idle);
      if (idle) {
        this._assign(idle, { data, resolve, reject });
      } else {
        this.queue.push({ data, resolve, reject });
      }
    });
  }

  _assign(entry, task) {
    entry.idle = false;
    this.pending.set(entry.worker, { resolve: task.resolve, reject: task.reject });
    entry.worker.postMessage(task.data);
  }
}

// Create once at startup, reuse forever
const pool = new WorkerPool('./worker.js');

module.exports = { pool };

Set the pool size to os.cpus().length - 1 — leave one core for the main thread and I/O operations. With a 4-core machine you get 3 worker threads. Tasks that arrive when all workers are busy wait in the queue rather than spinning up unlimited threads.

When Should You Actually Use Worker Threads?

Worker Threads shine when:

  • You're doing CPU-bound computation that takes more than ~50ms
  • You can't (or don't want to) offload to a background job queue
  • You need to process large data buffers efficiently — you can even use SharedArrayBuffer to share memory between threads with zero-copy performance

They are not the fix for slow database queries or sluggish external API calls. That's what async/await and the event loop already handle perfectly. Don't reach for Worker Threads because your Postgres queries are slow — that's a different problem with different solutions.

The Quick Mental Model

Task Type Solution
Waiting for DB / HTTP / files async/await + event loop (already great)
CPU-intensive, one-off new Worker() promise wrapper
CPU-intensive, sustained load Worker pool with fixed thread count
CPU-intensive, truly massive Separate service or job queue

The Takeaway

"Don't block the event loop" was great advice when Worker Threads didn't exist. But Node.js has grown up. CPU-intensive work no longer means "rewrite in Go" or "spin up a Python microservice." You can handle it right there in Node.js, keeping your architecture simpler, your deployments fewer, and your on-call rotation saner.

Try it today. Find one route that's doing something CPU-heavy — report generation, image manipulation, data parsing — and move the computation into a worker. Your event loop latency will drop, your p99 response times will improve, and you'll have a satisfying answer the next time someone tells you Node.js can't do real parallelism.

Got a creative Worker Thread use case? Drop it in the comments — I'm always curious what people are computing in there.

← Back to all posts