Bird
Raised Fist0
Node.jsframework~5 mins

Master and worker processes in Node.js - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is the role of the master process in Node.js cluster?
The master process manages worker processes. It creates, monitors, and distributes tasks to workers to balance the load.
Click to reveal answer
beginner
What is a worker process in Node.js cluster?
A worker process is a child process created by the master. It runs the application code and handles incoming requests.
Click to reveal answer
intermediate
How do master and worker processes communicate in Node.js?
They communicate using an internal messaging system with events and messages passed between the master and workers.
Click to reveal answer
beginner
Why use master and worker processes in Node.js?
To use multiple CPU cores efficiently by running multiple instances of the app, improving performance and reliability.
Click to reveal answer
intermediate
What happens if a worker process crashes in a Node.js cluster?
The master detects the crash and can automatically create a new worker to replace it, keeping the app running smoothly.
Click to reveal answer
What does the master process do in a Node.js cluster?
AStores data in a database
BHandles all HTTP requests directly
CRuns the user interface
DCreates and manages worker processes
How many worker processes can a Node.js cluster have by default?
AUnlimited without limits
BOnly one
COne per CPU core
DExactly two
What happens when a worker process crashes in a cluster?
AThe whole application stops
BThe master can restart a new worker
CNothing, the worker stays crashed
DThe master process crashes too
Which module in Node.js helps create master and worker processes?
Acluster
Bhttp
Cfs
Devents
How do master and worker processes share workload?
AMaster distributes incoming connections to workers
BWorkers share memory directly
CMaster runs all code, workers idle
DWorkers communicate with each other directly
Explain how master and worker processes work together in Node.js cluster.
Think about who manages and who does the work.
You got /5 concepts.
    Describe what happens when a worker process crashes and how the cluster handles it.
    Focus on fault tolerance and recovery.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main role of the master process in Node.js cluster module?
      easy
      A. To create and manage worker processes
      B. To handle HTTP requests directly
      C. To run the application code
      D. To listen on network ports

      Solution

      1. Step 1: Understand the master process role

        The master process is responsible for creating and managing worker processes in the cluster module.
      2. Step 2: Differentiate master from worker tasks

        Workers run the app code and handle requests, while the master only manages them.
      3. Final Answer:

        To create and manage worker processes -> Option A
      4. Quick Check:

        Master manages workers [OK]
      Hint: Master only manages workers, does not run app code [OK]
      Common Mistakes:
      • Thinking master handles requests directly
      • Confusing master with worker process
      • Assuming master runs app code
      2. Which of the following is the correct way to check if the current process is the master in a Node.js cluster?
      easy
      A. if (process.isWorker) { ... }
      B. if (cluster.isWorker) { ... }
      C. if (process.isMaster) { ... }
      D. if (cluster.isMaster) { ... }

      Solution

      1. Step 1: Recall cluster module properties

        The cluster module provides isMaster and isWorker boolean properties to identify process roles.
      2. Step 2: Identify correct syntax

        To check if current process is master, use cluster.isMaster, not process properties.
      3. Final Answer:

        if (cluster.isMaster) { ... } -> Option D
      4. Quick Check:

        Use cluster.isMaster to check master process [OK]
      Hint: Use cluster.isMaster, not process properties [OK]
      Common Mistakes:
      • Using process.isMaster which does not exist
      • Confusing isWorker with isMaster
      • Using wrong object for the check
      3. Consider this Node.js cluster code snippet:
      const cluster = require('cluster');
      const http = require('http');
      
      if (cluster.isMaster) {
        cluster.fork();
        cluster.fork();
      } else {
        http.createServer((req, res) => {
          res.end('Worker ' + process.pid);
        }).listen(8000);
      }

      What will happen when you visit http://localhost:8000?
      medium
      A. You get response 'Worker <pid>' from one of the two workers
      B. You get response 'Worker <pid>' from the master process
      C. The server crashes because master listens on port
      D. No response because no server is created

      Solution

      1. Step 1: Identify which process creates the server

        The else block runs in worker processes, which create the HTTP server listening on port 8000.
      2. Step 2: Understand request handling

        Requests are handled by one of the two worker processes forked by the master, each responding with its process ID.
      3. Final Answer:

        You get response 'Worker <pid>' from one of the two workers -> Option A
      4. Quick Check:

        Workers handle requests, master does not listen [OK]
      Hint: Only workers create servers and respond [OK]
      Common Mistakes:
      • Thinking master handles requests
      • Assuming master listens on port
      • Believing no server is created
      4. Given this code snippet:
      const cluster = require('cluster');
      if (cluster.isMaster) {
        cluster.fork();
        cluster.fork();
      } else {
        console.log('Worker started');
      }

      Why might the workers never start properly?
      medium
      A. Because the master process forgot to require('http')
      B. Because the workers have no code to keep them alive
      C. Because cluster.fork() is called inside the else block
      D. Because cluster.isMaster is always false

      Solution

      1. Step 1: Analyze worker code behavior

        The workers only log 'Worker started' and then exit immediately because no server or event loop keeps them alive.
      2. Step 2: Understand cluster.fork usage

        cluster.fork() is correctly called in master block, so workers start but exit quickly.
      3. Final Answer:

        Because the workers have no code to keep them alive -> Option B
      4. Quick Check:

        Workers exit if no server or event loop runs [OK]
      Hint: Workers need active code (like server) to stay alive [OK]
      Common Mistakes:
      • Thinking missing http require stops workers
      • Confusing cluster.fork placement
      • Assuming cluster.isMaster is always false
      5. You want to create a Node.js cluster that uses all CPU cores and restarts any worker that crashes. Which approach correctly implements this?
      hard
      A. Create workers manually without cluster module and restart them with setInterval
      B. Use cluster.fork() once and rely on master to restart automatically
      C. Use cluster.fork() for each CPU core and listen to 'exit' event to fork a new worker
      D. Use cluster.isWorker to fork new workers inside each worker process

      Solution

      1. Step 1: Use all CPU cores with cluster.fork()

        Fork one worker per CPU core by looping over the number of CPUs.
      2. Step 2: Restart crashed workers by listening to 'exit'

        Listen to the 'exit' event on cluster to detect worker crashes and fork a new worker to replace it.
      3. Final Answer:

        Use cluster.fork() for each CPU core and listen to 'exit' event to fork a new worker -> Option C
      4. Quick Check:

        Fork per CPU + restart on exit [OK]
      Hint: Fork per CPU and restart on 'exit' event [OK]
      Common Mistakes:
      • Forking only once and expecting auto-restart
      • Restarting workers inside workers themselves
      • Not handling worker crashes properly