When and how do you use worker threads?

Question

Accepted Answer

**Worker threads** let Node run JavaScript on **separate threads** with true parallelism — solving Node's biggest limitation: CPU-intensive work blocking the single main thread (and thus all requests). Use them for heavy computation, not for I/O (which the event loop already handles efficiently).

## The problem they solve

```js
// ❌ this CPU-heavy work BLOCKS the event loop → all requests freeze for its duration
app.get("/hash", (req, res) => {
  const result = expensiveComputation(); // e.g. heavy crypto, image processing
  res.json(result); // meanwhile, no other request can be handled
});
```

Node runs your JS on one thread. A long synchronous computation blocks **everything** — the event loop can't process other requests until it finishes. Worker threads move that work off the main thread.

## Using a worker thread

```js
// main.js
import { Worker } from "worker_threads";

// the main thread stays free to handle other requests while this runs
const result = await runHeavyTask({ numbers: [...] });
```

```js
// worker.js — runs in parallel, on its own thread
import { workerData, parentPort } from "worker_threads";

const result = expensiveComputation(workerData); // doesn't block the main thread
parentPort.postMessage(result);                    // send the result back
```

The worker runs independently; the main thread continues serving requests and gets the result via a message when done.

## When to use (and not)

```text
✓ USE for CPU-bound work: image/video processing, encryption, compression,
  big data parsing, complex calculations, ML inference
✗ DON'T use for I/O (DB, files, HTTP) — the async event loop already handles
  that efficiently; a worker would add overhead for no benefit
```

The rule: **workers for CPU-bound, the event loop for I/O-bound.**

## Worker threads vs child_process vs cluster

```text
worker_threads → share memory (efficient data passing), in-process threads — CPU work
child_process  → separate OS processes, run other programs — heavier isolation
cluster        → fork the whole server across CPUs — scale request handling
```

## Why it matters

Worker threads address Node's core weakness — CPU-bound tasks blocking the single-threaded event loop and freezing all concurrent requests.

Knowing to offload heavy computation to a worker (keeping the main thread responsive), and crucially **when** to use them (CPU-bound only, never for I/O), is what lets a Node service handle occasional heavy processing without sacrificing the concurrency that makes Node valuable.

For pooling workers in production, libraries like Piscina manage a thread pool efficiently.