How do you scale a Node.js app across multiple CPUs?

Question

Accepted Answer

A single Node process uses only **one CPU core** (its JS runs on one thread). To use all cores on a machine, you run **multiple Node processes** — via the `cluster` module, a process manager like PM2, or container orchestration — and load-balance requests across them.

## The problem

```text
A server with 8 CPU cores running ONE Node process → uses ~1 core, wastes 7.
Need multiple processes to utilize all cores and handle more concurrent load.
```

## The cluster module — fork worker processes

```js
import cluster from "cluster";
import { cpus } from "os";
import http from "http";

if (cluster.isPrimary) {
  const numCPUs = cpus().length;
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork(); // spawn one worker process per CPU core
  }
  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — restarting`);
    cluster.fork(); // restart a crashed worker (resilience)
  });
} else {
  // each worker runs the actual server; the OS load-balances connections across them
  http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}
```

The primary process forks one worker per core; all workers share the same port, and incoming connections are distributed among them — multiplying throughput. Crashed workers can be auto-restarted for resilience.

## In practice: use PM2 (cluster mode)

```bash
pm2 start app.js -i max   # run one instance per CPU core, with auto-restart & monitoring
```

Production apps usually use **PM2** (or similar) rather than hand-writing cluster code — it handles forking, load balancing, zero-downtime reloads, monitoring, and restarts.

## Or scale with containers/orchestration

```text
Run ONE Node process per container, and run MANY containers (Kubernetes, ECS),
with a load balancer in front. This is the modern cloud approach — simpler
per-process model, scaling handled by the orchestrator across machines.
```

## The critical caveat: statelessness

```text
Multiple processes don't share memory. So:
⚠️ Don't store sessions/state in process memory → use Redis/a shared store
⚠️ In-memory caches aren't shared across workers → use Redis for shared cache
⚠️ WebSocket connections live on one worker → use a Redis adapter to coordinate
```

For multi-process scaling to work, your app must be **stateless** — any shared state (sessions, cache, real-time coordination) must live in an external store like Redis, not in process memory.

## Why it matters

Utilizing all CPU cores is essential to get full performance from a Node server — a single process leaves most of a multi-core machine idle.

Knowing the options (cluster module, PM2 cluster mode, or one-process-per-container with orchestration) and, crucially, the **statelessness requirement** (external Redis-backed sessions/cache/real-time, since processes don't share memory) is fundamental to scaling Node in production.

This horizontal scaling, combined with statelessness, is how Node apps handle high traffic reliably.