How do you gracefully shut down a worker in Node.js clustering?

Graceful shutdown involves calling worker.disconnect() to stop accepting new connections, waiting for existing requests to finish, and then killing the process if needed. This prevents abrupt connection drops for active clients.

A graceful shutdown is important in production to avoid dropping in-flight requests. Instead of immediately killing a worker with worker.kill(), you first disconnect it so it stops accepting new connections, let it finish processing ongoing requests, and optionally force-kill it if it takes too long using a timeout.

Graceful Worker Shutdown

Graceful Shutdown Steps

1
Call worker.disconnect() — closes the IPC channel and stops accepting connections
2
Wait for the 'disconnect' event to confirm clean disconnection
3
Set a timeout (e.g., 5s) as a safety net to force-kill if requests hang
4
Call worker.kill() to forcefully terminate if disconnect timeout is exceeded
5
Perform cleanup in the worker: close DB connections, flush caches, finalize logs

Difficulty: 5/10

Topics: cluster module, process signals, graceful shutdown

Scenario Questions

0-2 years experience

1
You have a Node.js app using the cluster module with a single worker. How would you implement a graceful shutdown when the process receives SIGTERM?
2
What steps would you take to make sure the worker finishes any in‑flight HTTP requests before exiting?
3
If you call worker.disconnect() and immediately exit the master, what could happen to ongoing requests?

2-5 years experience

1
We noticed that after sending a SIGINT to our clustered server, some requests are being dropped. Walk me through how you'd debug the shutdown sequence and what changes you'd make.
2
Explain the trade‑offs between using worker.disconnect() versus worker.kill() in a production service that must meet an SLA during deployments.
3
Our monitoring shows workers sometimes hang after we call process.exit() in the master. How would you modify the shutdown logic to avoid this?

5-8 years experience

1
Design a shutdown protocol for a cluster of 20 workers handling long‑running jobs, ensuring no job is lost and the system can scale down gracefully under load spikes.
2
How would you coordinate graceful shutdown across multiple Node.js services that communicate via message queues, considering back‑pressure and message acknowledgment?
3
Discuss the performance impact of waiting for each worker's 'disconnect' event versus forcing termination after a timeout. When would you choose each approach?

8+ years experience

1
Our platform is migrating from a monolithic Node.js app to microservices but still uses clustering for CPU scaling. How would you evolve the graceful shutdown strategy to support rolling upgrades across services while minimizing downtime and keeping compatibility with legacy workers?
2
At a company‑wide level we need a standardized shutdown framework for all Node.js services, some using cluster and others using worker_threads. What architectural guidelines would you propose, and how would you drive cross‑team adoption and backward compatibility?

Follow-up Questions

❓Can you sketch the shutdown handler code you would use?
❓What would you monitor to confirm that all workers shut down cleanly?
❓How do you handle a worker that doesn't exit within the timeout?