cluster & multi-process scaling in nodejs

The Cluster module is one of the most powerful tools in Node.js for scaling applications. While Node.js runs on a single thread, the Cluster module allows you to "fork" your main process into multiple child processes, enabling your app to utilize all available CPU cores on your server. 1. Why use Cluster? A single instance of Node.js runs on a single CPU core. If you have a server with 8 cores (like many modern AWS EC2 instances), 7 of those cores will sit idle while your app struggles under heavy traffic. The Cluster module solves this by: Load Balancing: It creates a "Master" process that manages "Worker" processes. Performance: It distributes incoming network connections across all workers. Reliability: If one worker crashes, the others keep the server running, and the master can spawn a replacement. 2. How it Works (The Master-Worker Model) The Master: Does not execute your actual app logic. Its only job is to spawn workers and manage them. The Workers: These are the processes that actually listen for requests and run your code. The Sharing: All workers share the same server ports (e.g., Port 3000). The Master process uses a Round-Robin approach to hand off incoming connections to the workers. 3. Basic Implementation const cluster = require('cluster'); const http = require('http'); const os = require('os'); if (cluster.isMaster) {   const numCPUs = os.cpus().length;   console.log(`Master process ${process.pid} is running`);   console.log(`Forking for ${numCPUs} CPUs...\n`);   // Create a worker for each CPU core   for (let i = 0; i < numCPUs; i++) {     cluster.fork();   }   // Restart a worker if it dies   cluster.on('exit', (worker, code, signal) => {     console.log(`Worker ${worker.process.pid} died. Spawning a new one...`);     cluster.fork();   }); } else {   // WORKER PROCESSES: They share the same TCP connection   http.createServer((req, res) => {     res.writeHead(200);     res.end(`Handled by worker ${process.pid}\n`);   }).listen(3000);   console.log(`Worker ${process.pid} started`); } 4. Cluster vs. Worker Threads Since we recently discussed Worker Threads, it's important to know the difference: Feature child_process.fork() worker_threads Instance New Process (New PID) New Thread (Same PID) Memory Completely Isolated Shared Memory available Best For Scaling Throughput (Handling more HTTP requests) CPU Tasks (Math, Image processing) Communication IPC (JSON messages) MessageChannel / SharedArrayBuffer 5. Limitations and State Because workers are separate processes, they do not share memory . This means: No Local Sessions: You cannot store user sessions in a local variable (like const users = {} ). One worker won't know what the other worker has stored. The Solution: You must use an external "state" store like Redis or MongoDB to manage sessions or shared data across your cluster. 6. Production Tip: Use PM2 While the native Cluster module is great, in professional environments, most developers use PM2 (Process Manager 2). PM2 has a built-in "Cluster Mode" that handles all the forking and zero-downtime restarts for you automatically with a simple command: pm2 start app.js -i max