Node.js Cluster Interview Questions & Flashcards

Prepare for Node.js backend interviews with a focused flashcard set covering Cluster and Worker Process APIs. This collection helps developers understand how Node.js scales applications across multiple CPU cores using worker processes, inter-process communication (IPC), and workload distribution. The cards explore essential concepts such as Cluster architecture, primary and worker processes, process lifecycle events, worker management, graceful shutdown strategies, message passing, connection handling, scheduling policies, and fault recovery. You'll learn how worker processes are created, monitored, disconnected, restarted, and terminated in production environments. The set also covers practical topics frequently discussed in middle, senior, and system design interviews, including load balancing strategies, round-robin scheduling, process isolation, worker health monitoring, zero-downtime deployments, horizontal scaling, and the trade-offs between Cluster and Worker Threads. Whether you're preparing for a technical interview, improving your backend architecture skills, or building high-performance Node.js applications, these flashcards provide a fast and effective way to reinforce key concepts. Each card is designed to help you understand not only the API itself but also real-world usage patterns, performance considerations, operational challenges, and architectural decisions commonly encountered in modern backend systems. Ideal for Node.js developers, backend engineers, full-stack developers, technical leads, and software architects seeking a deeper understanding of scalable server-side JavaScript applications. You may also be interested in: Master Node.js: From Basics to Production Node.js Stream Module Node.js Child Process Module Node.js Buffer API Interview Questions Node.js Crypto Module Node.js Operating System Module Node.js File System Module

You can start studying this pack. You'll receive 132 messages to help you review each card multiple times, following the principles of the forgetting curve.

Learn more about the spaced repetition method.

Cluster

Clusters of Node.js processes can be used to run multiple instances of Node.js that can distribute workloads among their application threads.

When process isolation is not needed, use the worker_threads module instead, which allows running multiple application threads within a single Node.js instance.

1/33

How it works

The worker processes are spawned using the child_process.fork() method, so that they can communicate with the parent via IPC and pass server handles back and forth.

The cluster module supports two methods of distributing incoming connections.

2/33

Class: Worker

Extends: <EventEmitter>

A Worker object contains all public information and method about a worker. In the primary it can be obtained using cluster.workers. In a worker it can be obtained using cluster.worker.

3/33

Event: disconnect

Similar to the cluster.on('disconnect') event, but specific to this worker.

4/33

Event: 'error'

This event is the same as the one provided by child_process.fork().

Within a worker, process.on('error') may also be used.

5/33

Event: 'exit'

code <number> The exit code, if it exited normally.

signal <string> The name of the signal (e.g., 'SIGHUP') that caused the process to be killed.

Similar to the cluster.on('exit') event, but specific to this worker.

6/33

Event: 'listening'

address <Object>

Similar to the cluster.on('listening') event, but specific to this worker.

It is not emitted in the worker.

7/33

Event: 'message'

message <Object>

handle <undefined> | <Object>

Similar to the 'message' event of cluster, but specific to this worker.

Within a worker, process.on('message') may also be used.

8/33

Event: 'online'

Similar to the cluster.on('online') event, but specific to this worker.

9/33

worker.disconnect()

Returns: <cluster.Worker> A reference to worker.

In a worker, this function will close all servers, wait for the 'close' event on those servers, and then disconnect the IPC channel.

In the primary, an internal message is sent to the worker causing it to call .disconnect() on itself.

10/33

worker .exitedAfterDisconnect

This property is true if the worker exited due to .disconnect(). If the worker exited any other way, it is false. If the worker has not exited, it is undefined.

11/33

worker.id

Each new worker is given its own unique id, this id is stored in the id.

While a worker is alive, this is the key that indexes it in cluster.workers.

12/33

worker.isConnected()

This function returns true if the worker is connected to its primary via its IPC channel, false otherwise. A worker is connected to its primary after it has been created. It is disconnected after the 'disconnect' event is emitted.

13/33

worker.isDead()

This function returns true if the worker's process has terminated (either because of exiting or being signaled). Otherwise, it returns false.

14/33

worker.kill([signal])

signal <string> Name of the kill signal to send to the worker process. Default: 'SIGTERM'

This function will kill the worker. In the primary worker, it does this by disconnecting the worker.process, and once disconnected, killing with signal. In the worker, it does it by killing the process with signal.

15/33

worker.process

All workers are created using child_process.fork(), the returned object from this function is stored as .process. In a worker, the global process is stored.

16/33

worker.send()

Send a message to a worker or primary, optionally with a handle.

17/33

Event: disconnect

worker <cluster.Worker>

Emitted after the worker IPC channel has disconnected. This can occur when a worker exits gracefully, is killed, or is disconnected manually (such as with worker.disconnect()).

18/33

Event: exit

When any of the workers die, the cluster module will emit the 'exit' event.

19/33

Event: fork

worker <cluster.Worker>

When a new worker is forked, the cluster module will emit a 'fork' event. This can be used to log worker activity and create a custom timeout.

20/33

Event: listening

worker <cluster.Worker>

address <Object>

After calling listen() from a worker, when the 'listening' event is emitted on the server, a 'listening' event will also be emitted on cluster in the primary.

21/33

Event: message

worker <cluster.Worker>

message <Object>

handle <undefined> | <Object>

Emitted when the cluster primary receives a message from any worker.

22/33

Event: online

worker <cluster.Worker>

After forking a new worker, the worker should respond with an online message. When the primary receives an online message, it will emit this event.

23/33

Event: setup

settings <Object>

Emitted every time .setupPrimary() is called.

The settings object is the cluster.settings object at the time .setupPrimary() was called and is advisory only, since multiple calls to .setupPrimary() can be made in a single tick.

24/33

cluster .disconnect([callback])

callback <Function> Called when all workers are disconnected and handles are closed.

Calls .disconnect() on each worker in cluster.workers. When they are disconnected, all internal handles will be closed, allowing the primary process to die gracefully if no other event is waiting.

25/33

cluster.fork([env])

env <Object> Key/value pairs to add to the worker process environment.

Spawns a new worker process. This can only be called from the primary process.

26/33

cluster.isPrimary

<boolean> True if the process is a primary. This is determined by the process.env.NODE_UNIQUE_ID. If process.env.NODE_UNIQUE_ID is undefined, then isPrimary is true.

27/33

cluster.isWorker

<boolean> True if the process is not a primary (it is the negation of cluster.isPrimary).

28/33

cluster.schedulingPolicy

The scheduling policy, either cluster.SCHED_RR for round-robin or cluster.SCHED_NONE to leave it to the operating system.

29/33

cluster.settings

This object is not intended to be changed or set manually.

30/33

cluster.setupPrimary

setupPrimary is used to change the default 'fork' behavior. Once called, the settings will be present in cluster.settings.

31/33

cluster.worker

A reference to the current worker object. Not available in the primary process.

32/33

cluster.workers

A hash that stores the active worker objects, keyed by id field. This makes it easy to loop through all the workers.

33/33