Hoe schaal je een Node.js-app over meerdere CPU's?

Question

IT Interview Practice · Accepted Answer

Een enkel Node-proces gebruikt slechts **één CPU-kern** (de JS draait op één thread). Om alle kernen op een machine te gebruiken, voer je **meerdere Node-processen** uit — via de `cluster`-module, een procesmanager zoals PM2, of container-orchetratie — en balanceer je aanvragen over deze processen.

## Het probleem

```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.
```

## De cluster-module — fork worker-processen

```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);
}
```

Het primaire proces forkt één worker per kern; alle workers delen dezelfde poort, en inkomende verbindingen worden over hen verdeeld — wat de doorvoer vermenigvuldigt. Gecrasde workers kunnen automatisch opnieuw worden gestart voor veerkracht.

## In praktijk: gebruik PM2 (cluster mode)

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

Productie-apps gebruiken meestal **PM2** (of vergelijkbaar) in plaats van handmatig cluster-code te schrijven — het handelt forking, load balancing, zero-downtime reloads, monitoring en restarts af.

## Of schaal met containers/orchetratie

```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.
```

## De kritieke kanttekening: staatloosheid

```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
```

Opdat multi-process scaling werkt, moet je app **staatloos** zijn — eventuele gedeelde status (sessies, cache, real-time coördinatie) moet in een extern archief zoals Redis leven, niet in procesgeheugen.

## Waarom het belangrijk is

Het benutten van alle CPU-kernen is essentieel om volledige prestaties uit een Node-server te krijgen — een enkel proces laat het meeste van een multi-core machine inactief.

De opties kennen (cluster-module, PM2 cluster mode, of één proces per container met orchetratie) en, vooral, de **staatloosheid-vereiste** (extern Redis-ondersteunde sessies/cache/real-time, omdat processen geen geheugen delen) is fundamenteel voor het schalen van Node in productie.

Deze horizontale schaling, gecombineerd met staatloosheid, is hoe Node-apps betrouwbaar hoge verkeersvoluming verwerken.

Het probleem

De cluster-module — fork worker-processen

In praktijk: gebruik PM2 (cluster mode)

Of schaal met containers/orchetratie

De kritieke kanttekening: staatloosheid

Waarom het belangrijk is

Gerelateerde vragen