Como você dimensiona uma aplicação Node.js em múltiplas CPUs?

Question

Accepted Answer

Um único processo Node.js usa apenas **um núcleo de CPU** (seu código JS é executado em uma única thread). Para usar todos os núcleos em uma máquina, você executa **múltiplos processos Node.js** — via módulo `cluster`, um gerenciador de processos como PM2, ou orquestração de contêineres — e distribui requisições entre eles com balanceamento de carga.

## O problema

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

## O módulo cluster — processos worker bifurcados

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

O processo primário bifurca um worker por núcleo; todos os workers compartilham a mesma porta, e as conexões recebidas são distribuídas entre eles — multiplicando a taxa de transferência. Workers com falha podem ser reiniciados automaticamente para resiliência.

## Na prática: use PM2 (cluster mode)

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

Aplicações em produção geralmente usam **PM2** (ou similar) em vez de escrever manualmente código de cluster — ele trata de bifurcação, balanceamento de carga, recarregamentos sem parada de serviço, monitoramento e reinicializações.

## Ou dimensione com contêineres/orquestração

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

## A ressalva crítica: ausência de estado

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

Para que o dimensionamento multi-processo funcione, sua aplicação deve ser **sem estado** — qualquer estado compartilhado (sessões, cache, coordenação em tempo real) deve residir em um armazenamento externo como Redis, não na memória do processo.

## Por que isso importa

Utilizar todos os núcleos de CPU é essencial para obter desempenho completo de um servidor Node — um único processo deixa a maioria de uma máquina multi-núcleo ociosa.

Conhecer as opções (módulo cluster, modo cluster do PM2, ou um processo por contêiner com orquestração) e, crucialmente, o **requisito de ausência de estado** (sessões/cache/tempo real apoiados por Redis, já que os processos não compartilham memória) é fundamental para dimensionar Node em produção.

Este dimensionamento horizontal, combinado com ausência de estado, é como aplicações Node lidam com alto tráfego de forma confiável.