0x55aa
Back to Blog
nodejsbackendperformanceworker-threadsjavascript

🧵 Node.js Worker Threads: Because Your Event Loop Deserves a Break

|
6 min read

🧵 Node.js Worker Threads: Because Your Event Loop Deserves a Break

Here's a fun scenario: your Node.js API is humming along beautifully, handling hundreds of requests per second, when suddenly someone uploads a 50MB CSV file that needs to be parsed, transformed, and aggregated. Your event loop, which was previously an olympic sprinter, is now stuck pushing a boulder uphill — and every other request is waiting in line behind it, growing increasingly impatient.

This is the classic Node.js CPU-bound problem. And Worker Threads are the solution that too few developers reach for.

The Event Loop Is Not Your Personal CPU Slave

Node.js is famously single-threaded. Its superpower is the event loop — a clever mechanism that juggles thousands of async I/O operations (database queries, HTTP requests, file reads) without breaking a sweat. It does this by delegating the actual waiting to the OS and coming back when work is ready.

The catch? "Without breaking a sweat" only applies to waiting. If you hand the event loop actual computation — like encrypting large payloads, running image processing, parsing massive JSON blobs, or executing complex algorithms — it can't delegate that anywhere. It just... grinds through it. Alone. While everything else waits.

Imagine a brilliant receptionist (the event loop) who can handle 200 phone calls by putting people on hold and cycling between them. Now imagine you hand that same receptionist a 500-page document to proofread right now, before taking another call. Everyone on hold is furious. That's your API during a CPU spike.

Worker Threads give your receptionist colleagues who can handle the grunt work in a separate office.

Setting Up Your First Worker Thread

Worker Threads have been stable since Node.js 12 and are part of the core worker_threads module — no npm install needed.

Here's the pattern: you spawn a worker, pass it data via a message, and get results back asynchronously — without blocking the main thread at all.

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

function heavyComputation(data) {
  // Simulate CPU-intensive work: e.g., computing a hash, aggregating stats
  let result = 0;
  for (let i = 0; i < data.iterations; i++) {
    result += Math.sqrt(i) * Math.PI;
  }
  return { result: result.toFixed(4), processed: data.iterations };
}

const output = heavyComputation(workerData);
parentPort.postMessage(output);

// main.js — your Express route or wherever you need it
const { Worker } = require('worker_threads');
const path = require('path');

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

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

// In your Express route
app.post('/crunch', async (req, res) => {
  try {
    const result = await runWorker({ iterations: 100_000_000 });
    res.json(result);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

The magic here: runWorker returns a Promise, so your route stays async and non-blocking. While the worker is crunching numbers in its own thread, your event loop is free to handle other incoming requests. No freezing. No timeouts. No angry users.

The Worker Pool Pattern (When You Mean Business)

Spawning a new thread for every request has overhead — thread creation isn't free. For high-traffic scenarios, you want a worker pool: a fixed set of pre-warmed workers you reuse.

const { Worker } = require('worker_threads');

class WorkerPool {
  constructor(workerScript, poolSize = 4) {
    this.workers = [];
    this.queue = [];

    for (let i = 0; i < poolSize; i++) {
      const worker = new Worker(workerScript);
      worker.on('message', (result) => this._handleResult(worker, result));
      worker.on('error', (err) => this._handleError(worker, err));
      this.workers.push({ worker, busy: false });
    }
  }

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

  _dispatch(slot, data, resolve, reject) {
    slot.busy = true;
    slot.resolve = resolve;
    slot.reject = reject;
    slot.worker.postMessage(data);
  }

  _handleResult(worker, result) {
    const slot = this.workers.find((w) => w.worker === worker);
    slot.resolve(result);
    slot.busy = false;
    if (this.queue.length > 0) {
      const next = this.queue.shift();
      this._dispatch(slot, next.data, next.resolve, next.reject);
    }
  }

  _handleError(worker, err) {
    const slot = this.workers.find((w) => w.worker === worker);
    slot.reject(err);
    slot.busy = false;
  }
}

// Initialize once, reuse forever
const pool = new WorkerPool('./worker.js', 4);

app.post('/crunch', async (req, res) => {
  const result = await pool.run(req.body);
  res.json(result);
});

This pool creates 4 workers at startup and queues incoming tasks when all workers are busy. It's the same pattern database connection pools use — and for the same reason: managing expensive resources efficiently.

When Should You Actually Use This?

Worker Threads are the right tool when you have genuinely CPU-bound work:

  • Parsing large files — CSVs, XML, massive JSON payloads
  • Image or video processing — resizing, compression, format conversion
  • Cryptographic operations — generating keys, hashing large datasets
  • Data aggregation — complex stats over large arrays
  • ML inference — running models on the server side

They are not the right tool for:

  • Regular database queries (use async/await + connection pools)
  • HTTP requests to other services (async handles this perfectly)
  • File I/O (Node's async fs module already handles this off the main thread via libuv)

A quick mental test: "Is my code waiting for something external, or is it actively computing?" If it's computing, consider a worker.

The Gotcha You Need to Know

Workers don't share memory by default — data is cloned (serialized/deserialized) when passed between threads via postMessage. For most use cases, this is fine. But if you're passing enormous buffers, use SharedArrayBuffer or transfer ownership with { transfer: [buffer] } to avoid the copy cost.

Also, workers can't access DOM APIs (they run in a Node context, not a browser), and they don't share global state with the main thread. Each worker is essentially its own tiny Node.js process with its own module cache.

Your Event Loop Will Thank You

The single biggest mistake Node.js developers make with CPU work is assuming "it's JavaScript, it'll be fine." It won't. One miscalculated synchronous loop can tank your entire API's response times for every user.

Worker Threads give you a first-class, production-ready escape hatch built directly into Node. No native addons, no child_process gymnastics, no external queues for simple cases — just threads.

Your event loop is a specialist. Let it specialize. Hand off the heavy lifting to workers that were born to carry it.

Want to go deeper? Try profiling a real CPU bottleneck in your app with --inspect and Chrome DevTools, then benchmark the before/after with autocannon or wrk. The difference will make you a Worker Threads believer.

What's your current strategy for CPU-heavy work in Node? Drop it in the comments — I'd love to hear if you're using worker pools, child processes, or a queue like BullMQ.

Thanks for reading!

Back to all posts