Suggest an edit

Improve this article

Refine the answer for “How does cluster help scale an application?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## 1. The problem of being single-threaded

Node.js is **single-threaded** by nature -
all JavaScript runs on **one thread** with **one event loop**.

That means:

- one Node.js app can use **only one CPU core**;
- if the server has multiple cores (as most do), the rest sit **idle**;
- under heavy request load, the **event loop can get overwhelmed**, and the server starts to lag.

## 2. What `cluster` does

> The `cluster` module lets you **run several copies (workers)** of your application
> - one per CPU core - and **spread the load** across them.

In other words:

> `cluster` turns one Node.js server into a **pool of independent processes**,
> running in parallel, each with its own event loop and memory.

## 3. How it works

### The `cluster` architecture:

```javascript
┌───────────────────────┐
│  Master process         │
│  - listens on a port (e.g. 3000) │
│  - creates workers (via fork) │
└──────────────┬────────┘
               │
   ┌───────────┴───────────┐
   │           │           │
   ▼           ▼           ▼
Worker 1   Worker 2   Worker 3   ...   Worker N
(port 3000) (port 3000) (port 3000)
```

Every **worker**:

- is a **separate Node.js process**;
- has its own **event loop**, its own runtime, its own memory;
- listens on **the same port** as the others.

The master process:

- accepts incoming connections,
- distributes requests **among workers** (using *Round Robin*),
- watches over the workers' health and can **restart** them on failure.

## 4. An example of scaling with `cluster`

```javascript
import cluster from 'cluster';
import http from 'http';
import os from 'os';

if (cluster.isPrimary) {
  const numCPUs = os.cpus().length;
  console.log(`Primary process ${process.pid}, starting ${numCPUs} workers...`);

// Create workers, one per core
  for (let i = 0; i < numCPUs; i++) cluster.fork();

cluster.on('exit', (worker) => {
    console.log(`Worker ${worker.process.pid} exited. Restarting...`);
    cluster.fork();
  });

} else {
  // Each worker creates its own HTTP server
  http.createServer((req, res) => {
    res.end(`Response from worker ${process.pid}\n`);
  }).listen(3000);

console.log(`Worker ${process.pid} started`);
}
```

On an 8-core processor, this creates **8 workers**,
all of them listening on **port 3000** and sharing the load.

## 5. How `cluster` improves scalability

| Problem | What `cluster` does |
|---|---|
| Node.js uses only 1 core | Creates one process per core |
| One event loop is a bottleneck | Several event loops (one per worker) |
| One process can crash | The master restarts the worker |
| Rising traffic raises load | Requests spread across workers |
| Limits on memory and GC | Each worker has its own heap |

In short, `cluster` solves the **CPU-scaling problem**
("vertical scaling"), loading every processor core as much as possible.

## 6. Advantages of using `cluster`

| Advantage | Description |
|---|---|
| Multi-processor throughput | The app handles more requests at once |
| Error isolation | A crashed worker doesn't affect the rest |
| Automatic restart | The cluster can bring a worker back on its own |
| Load distribution | All workers listen on one port, load is even |
| Compatible with Express / Fastify / NestJS | An existing server can simply be "wrapped" |
| Production-ready | Used internally by PM2 and other process managers |

## 7. An example: load testing

Without `cluster` (1 process, 1 core):

- the server handles, say, **1,000 requests/sec**.

With `cluster` (8 workers on 8 cores):

- each worker handles ~1,000 requests/sec,
- total throughput is roughly **8,000 requests/sec**.

## 8. Scaling plus resilience

`cluster` doesn't just speed things up, it also makes the system **resilient**:

- if a worker hangs or crashes → the master **notices** via the `exit` event;
- it **spawns a new worker** to replace it;
- the server keeps running with no downtime.

## 9. How clustering is used in practice

**Commonly used:**

- in production servers (Express, Fastify, NestJS);
- in microservice and REST API systems;
- inside process managers, such as **PM2**;
- behind WebSocket or GraphQL server balancers.

**PM2** uses `cluster` under the hood:

```javascript
pm2 start app.js -i max
```

⟶ automatically starts as many workers as there are CPU cores.

## 10. Worth remembering

- Workers **don't share memory** → data needs to be synchronized through **IPC** or Redis.
- For **WebSocket connections**, **sticky sessions** are better, so one connection stays on one worker.
- Scaling across several machines needs an **external load balancer** (Nginx, HAProxy, AWS ELB).

## Summary

| Criterion | `cluster` |
|---|---|
| What it does | Runs several copies of the app across every CPU core |
| How it scales | Distributes requests across processes |
| Where it's used | Servers, APIs, production apps |
| Type of scaling | Vertical (across CPU cores) |
| Data exchange | Via IPC (Inter-Process Communication) |
| Benefits | Performance, resilience, fault tolerance |

**Conclusion:**

> The `cluster` module lets Node.js use **every available processor core**,
> creating a pool of workers that **serve requests in parallel**.
>
> It delivers **scalability, resilience and high performance** -
> without changing the application's logic.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts838 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.