¿Cómo escalas una app Node.js a través de múltiples CPUs?

Question

Accepted Answer

Un solo proceso de Node usa únicamente **un núcleo de CPU** (su JS se ejecuta en un hilo). Para usar todos los núcleos de una máquina, ejecutas **múltiples procesos de Node** — mediante el módulo `cluster`, un gestor de procesos como PM2 o la orquestación de contenedores — y balanceas la carga de las solicitudes entre ellos.

## El problema

```text
Un servidor con 8 núcleos de CPU ejecutando UN solo proceso de Node → usa ~1 núcleo, desperdicia 7.
Se necesitan múltiples procesos para utilizar todos los núcleos y manejar más carga concurrente.
```

## El módulo cluster — crear procesos worker

```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(); // crea un proceso worker por cada núcleo de CPU
  }
  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — restarting`);
    cluster.fork(); // reinicia un worker que se cayó (resiliencia)
  });
} else {
  // cada worker ejecuta el servidor real; el SO balancea las conexiones entre ellos
  http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}
```

El proceso primario crea un worker por núcleo; todos los workers comparten el mismo puerto, y las conexiones entrantes se distribuyen entre ellos — multiplicando el throughput. Los workers que se caen pueden reiniciarse automáticamente para mayor resiliencia.

## En la práctica: usa PM2 (modo cluster)

```bash
pm2 start app.js -i max   # ejecuta una instancia por núcleo de CPU, con auto-reinicio y monitoreo
```

Las apps en producción suelen usar **PM2** (o similar) en lugar de escribir a mano el código de cluster — gestiona el forking, el balanceo de carga, las recargas sin tiempo de inactividad, el monitoreo y los reinicios.

## O escala con contenedores/orquestación

```text
Ejecuta UN proceso de Node por contenedor, y ejecuta MUCHOS contenedores (Kubernetes, ECS),
con un balanceador de carga al frente. Este es el enfoque cloud moderno — modelo más simple
por proceso, con el escalado gestionado por el orquestador a través de las máquinas.
```

## La advertencia crítica: la ausencia de estado (statelessness)

```text
Múltiples procesos no comparten memoria. Por lo tanto:
⚠️ No almacenes sesiones/estado en la memoria del proceso → usa Redis/un almacén compartido
⚠️ Los cachés en memoria no se comparten entre workers → usa Redis para caché compartido
⚠️ Las conexiones WebSocket viven en un solo worker → usa un adaptador de Redis para coordinar
```

Para que el escalado multiproceso funcione, tu app debe ser **stateless** — cualquier estado compartido (sesiones, caché, coordinación en tiempo real) debe vivir en un almacén externo como Redis, no en la memoria del proceso.

## Por qué es importante

Utilizar todos los núcleos de CPU es esencial para obtener el máximo rendimiento de un servidor Node — un solo proceso deja la mayor parte de una máquina multinúcleo inactiva.

Conocer las opciones (módulo cluster, modo cluster de PM2, o un proceso por contenedor con orquestación) y, fundamentalmente, el **requisito de statelessness** (sesiones/caché/tiempo real respaldados por Redis externo, ya que los procesos no comparten memoria) es esencial para escalar Node en producción.

Este escalado horizontal, combinado con la ausencia de estado, es como las apps Node manejan tráfico alto de manera confiable.