Using Node.js worker_threads to Keep Your Server Responsive Under CPU Load

The problem: a blocking CPU task stalls your API

Imagine an endpoint that receives an uploaded image, resizes it to several thumbnails, and then stores the results. The resizing step uses a synchronous library that loops over every pixel. While this work runs, Node.js’ event loop cannot process other incoming requests, causing latency spikes and time‑outs under load.

Thesis: worker_threads let you move heavy CPU work off the event loop while keeping I/O responsive

The worker_threads module, stable since Node.js 14, creates separate JavaScript threads that run in parallel on multi‑core CPUs. Communication happens via message passing, so the main thread stays free to handle sockets, timers, and other I/O.

How it works: a minimal example

We’ll build two files: main.js (the thread that receives requests) and worker.js (the thread that does the image‑processing‑like work). The example uses a simple CPU‑intensive loop to stand in for real image processing.

main.js

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

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

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

// Simulate an incoming request
(async () => {
  console.log('Main thread', process.pid, '– start');
  const start = Date.now();
  const result = await runWorker({ iterations: 1e8 });
  const elapsed = Date.now() - start;
  console.log('Main thread', process.pid, '– result:', result, `in ${elapsed}ms`);
  // At this point the main thread could accept another request
})();

worker.js

const { parentPort, workerData, threadId } = require('worker_threads');

console.log('Worker thread', threadId, '– started');

// CPU‑intensive stand‑in: a tight loop that sums numbers
let sum = 0;
for (let i = 0; i < workerData.iterations; i++) {
  sum += i;
}

// Send the result back to the main thread
parentPort.postMessage(sum);

To try this:

1. Confirm you have Node.js 14 or newer: node --version (should print v14.x or higher).
2. Save the two snippets above as main.js and worker.js in the same folder.
3. Run node main.js in a terminal.

You should see output similar to:

Main thread 12345 – start
Worker thread 1 – started
Main thread 12345 – result: 49999950000000 in 1240ms

Notice that the main thread’s log appears immediately, the worker does its work, and the main thread logs the result only after the worker finishes. While the worker is busy, the main thread could still accept new connections because it never blocks on the loop.

Trade‑offs and practical limits

• Memory overhead: Each worker gets its own V8 heap and libuv thread pool. Spawning dozens of workers can quickly consume hundreds of megabytes.
• Message‑passing cost: Data sent between threads is serialized using the structured clone algorithm (similar to JSON). Large buffers should be transferred as Transferable objects (e.g., ArrayBuffer) to avoid copying.
• No shared mutable state: Workers cannot directly access variables in the parent thread. All coordination must happen via parentPort messages or explicit synchronization primitives like Atomics with a SharedArrayBuffer.
• Startup latency: Creating a worker takes a few milliseconds; for very short‑lived tasks a worker pool (reusing workers) is preferable.

To check that you’re not accidentally sharing state, try adding a global variable in main.js and logging it inside the worker – it will be undefined, confirming isolation.

Actionable next steps

1. Identify the CPU‑hot spots in your service (profiling with clinic.js or the built‑in --inspect flag).
2. Offload each spot to a worker, using a small pool if the work is frequent.
3. Measure latency before and after with a load‑testing tool (e.g., autocannon) to verify that the event loop stays responsive.
4. If you pass large binary data, replace postMessage(buffer) with postMessage(buffer, [buffer.buffer]) to transfer the underlying ArrayBuffer without copying.

By treating CPU‑intensive work as a separate thread, you keep your Node.js application responsive while still taking full advantage of modern multi‑core hardware.