Node.js Cluster: Scaling on a Single Machine

WHY IT EXISTS Node.js runs in a single thread, meaning a standard application on a multi-core machine can only use one CPU core, leaving the others idle. The cluster module was created to solve this by allowing a single Node.js application to spawn child processes that can run on separate cores, fully utilizing the machine's hardware for network applications.

THE MENTAL MODEL Think of the cluster module as a manager (the primary process) and a team of identical workers. The manager doesn't handle requests directly. Instead, it opens a server port and when a connection arrives, it hands it off to an available worker. All workers are clones of the same application, running in separate, isolated processes but sharing the same server port, allowing them to handle requests in parallel.

HOW IT WORKS When you run a script, the first process is the "primary" process (identified by cluster.isPrimary). The primary's job is to spawn worker processes using cluster.fork(). Each fork() call creates a new worker that runs the same file, but for them, cluster.isWorker is true. The primary process then distributes incoming connections to the workers, typically in a round-robin fashion. The primary can also monitor workers and restart them if they crash, providing resilience.

WHEN TO USE IT Use the cluster module to scale I/O-bound applications, especially HTTP servers, on a single multi-core machine. It provides a simple way to increase throughput and availability. It's a "scale-up" strategy that maximizes the resources of one server before you need to "scale-out" to multiple servers with an external load balancer.

WHEN NOT TO USE IT Do not use cluster for CPU-intensive tasks that need to share memory or communicate frequently. The overhead of inter-process communication (IPC) and forking separate processes is high. For CPU-bound work, the worker_threads module is a much better fit, as threads have lower overhead and can share memory more efficiently.

ONE CANONICAL EXAMPLE A typical web server setup involves checking if cluster.isPrimary. If true, the process loops through the number of available CPUs and calls cluster.fork() for each one. It also listens for the 'exit' event to restart a crashed worker. If cluster.isWorker is true, the process starts an HTTP server and listens for connections on a shared port, like 8000. This way, multiple processes handle requests on the same port, all managed by the primary.