Node.js Cluster Fork-Bomb: 400 Processes from DATABASE_URL

Node.js is single-threaded by design. The event loop model handles thousands of concurrent I/O operations without thread management overhead — and for most API servers sitting mostly idle between database calls, that is completely fine. The problem surfaces when you provision a modern eight-core server and watch seven of those cores sit at 0% utilization while the eighth queues every incoming request behind whatever is running right now.

The cluster module was Node's answer to this problem. It forks multiple Node.js processes — one per CPU core — and has them all share the same server port. Node's own round-robin scheduler on Linux and macOS, or the OS socket-level load balancing on Windows, distributes incoming connections across workers. Each worker is a fully independent V8 instance with its own event loop, heap, and garbage collector. They do not share memory. Communication between them happens through IPC message passing, which is slower than most engineers expect the first time they measure it.

Before you reach for the cluster module, it is worth being clear about what it actually solves. The most persistent misconception is that clustering makes individual requests faster. It does not. A single request still runs on a single thread from arrival to response. What clustering improves is throughput — the total number of requests your server can handle concurrently across all cores. If your bottleneck is a slow database query that adds 200ms to every request, spinning up eight workers does nothing for that. If your bottleneck is that your single-threaded event loop cannot accept new connections fast enough because it is busy processing the previous ones, clustering will help a great deal.

I have seen teams spend weeks tuning cluster configurations before realizing their actual bottleneck was a missing index on a Postgres query. Profile first, cluster second.

This guide covers how clustering works at the socket level, the production-grade patterns for running it safely without fork-bombs or silent state corruption, the right way to debug individual workers in a live cluster, and when to reach for worker threads instead of — or alongside — clustering.

How Node.js Cluster Master-Worker Model Actually Works

Node.js clustering forks a single process into multiple workers sharing the same server port. The master process listens for incoming connections and distributes them across workers using a round-robin algorithm (on Linux) or operating system scheduling (on Windows). Each worker runs its own V8 instance, event loop, and memory space — meaning no shared state between workers without an external store like Redis or a database.

In practice, clustering gives you near-linear CPU utilization for I/O-bound workloads. A single Node.js process uses one core; on a 4-core machine, clustering with 4 workers can handle roughly 4x the request throughput. However, each worker consumes about the same memory as the original process — 30–50 MB baseline per worker. Forking 400 workers from a DATABASE_URL misconfiguration means 12–20 GB of RAM instantly allocated, likely OOM-killing the host.

Use clustering when your application is CPU-bound (e.g., image processing, JSON serialization) or when you need to saturate multiple cores for high-throughput HTTP servers. Do not use clustering for trivial I/O tasks that Node.js already handles efficiently with a single thread — you gain nothing and waste memory. Always cap workers to os.cpus().length or a small multiple thereof.

How Node.js Clustering Actually Works Under the Hood

When you call cluster.fork(), Node.js spawns a child process using child_process.fork() under the hood, pointing it at the same entry-point script. The cluster module injects a NODE_UNIQUE_ID environment variable into the child's environment. Workers detect this variable at startup, which is how the same JavaScript file executes completely different code paths depending on whether cluster.isPrimary evaluates to true. The entire pattern — one file, two roles — flows from this one environment variable.

The socket story is the part most engineers get wrong the first time. Normally, two processes cannot bind to the same port — the second call to bind() returns EADDRINUSE. The cluster module sidesteps this entirely. The primary process creates the actual TCP server socket and binds it to the configured port. When a worker calls server.listen(), it does not attempt to bind anything to the OS. Instead, the cluster module intercepts that call at the Node.js layer and sends an IPC message to the primary process saying, in effect, 'I want to accept connections on port 3000.' The primary responds by passing the worker a handle — not a copy of the file descriptor, but a reference to the same underlying socket object. The OS sees exactly one socket bound to port 3000. Multiple workers hold references to it and can call accept() on it.

On Linux and macOS, Node's cluster module implements round-robin distribution internally inside the primary process (SCHED_RR). The primary accepts an incoming connection and then passes it to the next worker in rotation before any application code runs. On Windows, this mechanism does not apply — the OS distributes connections after they are established, using its own scheduler, which can produce noticeably uneven distribution under bursty traffic. One worker ends up with significantly more connections than others in a pattern that looks random but is actually an artifact of how the Windows TCP stack distributes accept() calls. You can force consistent round-robin behavior on all platforms by setting cluster.schedulingPolicy = cluster.SCHED_RR before the first cluster.fork() call.

One consequence that engineers often miss until it causes an incident: if the primary process dies, it takes the socket with it. The file descriptor closes. Every worker's handle becomes invalid simultaneously. There is no graceful handoff, no socket migration to a surviving worker — the socket is gone and all in-flight connections drop instantly. This is why the primary process deserves the same production monitoring attention you give to workers, including health checks, alerting, and automatic restart via a process manager.

const cluster = require('node:cluster');
const http = require('node:http');
const os = require('node:os');

const cpuCount = os.cpus().length;

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} running — forking ${cpuCount} workers`);

  // Force round-robin on all platforms.
  // Without this, Windows uses OS-level distribution which skews under load.
  cluster.schedulingPolicy = cluster.SCHED_RR;

  // One worker per logical CPU core is the correct starting point.
  // Forking more than cpuCount adds context-switching overhead without
  // adding parallelism — the OS can only run cpuCount threads simultaneously.
  for (let i = 0; i < cpuCount; i++) {
    cluster.fork();
  }

  // This is the naive respawn — it works fine in normal operation
  // and creates a fork-bomb the moment a bad deploy hits.
  // We fix this in the next section with backoff and a circuit breaker.
  cluster.on('exit', (worker, code, signal) => {
    console.log(
      `Worker ${worker.process.pid} exited ` +
      `(code: ${code}, signal: ${signal}). Respawning...`
    );
    cluster.fork();
  });

} else {
  // Workers share the TCP connection via handle passing from the primary.
  // server.listen() here does NOT call bind() on the OS —
  // it sends an IPC message to the primary requesting the socket handle.
  http
    .createServer((req, res) => {
      res.writeHead(200);
      res.end(`Handled by worker ${process.pid}\n`);
    })
    .listen(8000);

  console.log(`Worker ${process.pid} started`);
}

Production-Grade Cluster: Zero-Downtime Restarts and Health Monitoring

The naive implementation in the previous section has one critical production flaw: it calls cluster.fork() unconditionally every time a worker exits. In normal operation this is fine — a worker crashes, you spawn a replacement, life goes on. But imagine your new deployment has a bug that crashes every worker within 200 milliseconds of startup. The exit handler fires, spawns a replacement, which crashes in 200ms, fires the handler again, spawns another, crashes again. Within 10 seconds you have hundreds of doomed processes and a host that is effectively unusable.

I have seen this pattern play out in production three separate times across different teams, and the reason it keeps happening is that the naive version works perfectly during development and staging — it only fails when a specific kind of deploy goes wrong, which is exactly when you need your infrastructure to be most resilient.

Production-grade clustering requires three things that the naive version lacks. First: restart-rate limiting with exponential backoff, so a sustained crash loop does not consume all system resources. Second: a circuit breaker that stops forking entirely after a threshold of sustained failures and alerts your on-call rotation — because more workers will not fix a configuration problem. Third: graceful shutdown so workers finish in-flight requests before exiting, enabling zero-downtime rolling restarts during deployments.

Graceful shutdown during deployments works like this: you send SIGTERM to a worker. The worker calls server.close() to stop accepting new connections while letting existing ones complete. Once all connections drain, the worker calls process.exit(0). The primary sees the clean exit — identifiable because worker.exitedAfterDisconnect is true — and forks a replacement running the new code. Repeat for each worker in sequence. Users see no interruption. This is how you deploy Node.js in production without downtime and without a load balancer reconfiguration.

const cluster = require('node:cluster');
const http = require('node:http');
const os = require('node:os');

if (cluster.isPrimary) {
  const numCPUs = os.cpus().length;

  // Sliding window crash tracker.
  // We record a timestamp for each crash and purge entries older
  // than WINDOW_MS on every check. This gives us an accurate count
  // of crashes in the recent past without a growing data structure.
  const crashLog = [];
  const WINDOW_MS = 30_000;        // 30-second window
  const MAX_CRASHES_IN_WINDOW = 5; // open circuit after 5 rapid crashes
  const BASE_BACKOFF_MS = 1_000;   // start at 1 second
  let backoffMs = BASE_BACKOFF_MS;
  let circuitOpen = false;

  function recentCrashCount() {
    const cutoff = Date.now() - WINDOW_MS;
    // Purge old entries — crashLog is chronological so we can shift from front
    while (crashLog.length && crashLog[0] < cutoff) crashLog.shift();
    return crashLog.length;
  }

  function scheduleFork() {
    const crashes = recentCrashCount();

    if (crashes >= MAX_CRASHES_IN_WINDOW) {
      if (!circuitOpen) {
        circuitOpen = true;
        // In production, replace this with a real alert:
        // pagerduty.trigger(), slack.post(), SNS.publish(), etc.
        console.error(
          `[CIRCUIT OPEN] ${crashes} crashes in ${WINDOW_MS / 1000}s. ` +
          'Forking suspended. Manual intervention required.'
        );
      }
      return; // stop forking until a human resets this
    }

    console.warn(`Worker crashed. Backoff: ${backoffMs}ms before next fork.`);

    setTimeout(() => {
      crashLog.push(Date.now());
      cluster.fork();
      // Exponential backoff capped at 30 seconds
      backoffMs = Math.min(backoffMs * 2, 30_000);
    }, backoffMs);
  }

  cluster.schedulingPolicy = cluster.SCHED_RR;

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    if (worker.exitedAfterDisconnect) {
      // Clean, intentional shutdown — the worker was told to stop.
      // Fork immediately, reset backoff, and clear the circuit breaker
      // since this was not a crash.
      console.log(`Worker ${worker.id} gracefully shut down. Forking replacement.`);
      backoffMs = BASE_BACKOFF_MS;
      circuitOpen = false;
      cluster.fork();
      return;
    }

    console.error(
      `Worker ${worker.id} crashed — code: ${code}, signal: ${signal}`
    );
    scheduleFork();
  });

  // Graceful shutdown of the entire cluster on SIGTERM
  // (e.g., systemd stopping the service, Kubernetes pod termination)
  process.on('SIGTERM', () => {
    console.log('Primary received SIGTERM. Gracefully shutting down all workers.');
    for (const worker of Object.values(cluster.workers)) {
      worker.process.kill('SIGTERM');
    }
  });

} else {
  const server = http
    .createServer((req, res) => {
      res.writeHead(200);
      res.end(`Worker ${process.pid}`);
    })
    .listen(3000, () => {
      console.log(`Worker ${process.pid} ready`);
    });

  // Graceful shutdown: stop accepting, drain in-flight, exit cleanly.
  // The primary sees exitedAfterDisconnect === true and forks a replacement
  // without applying backoff — this is an intentional shutdown, not a crash.
  process.on('SIGTERM', () => {
    console.log(`Worker ${process.pid} draining...`);
    server.close(() => {
      console.log(`Worker ${process.pid} done. Exiting.`);
      process.exit(0);
    });

    // Safety valve: force exit after 30 seconds even if connections are stuck.
    // Without this, a keep-alive client can hold a worker open indefinitely.
    setTimeout(() => {
      console.warn(`Worker ${process.pid} force-exiting after drain timeout.`);
      process.exit(0);
    }, 30_000).unref();
  });
}

Shared State Pitfalls and the Right Way to Handle Cross-Worker Data

This is where most cluster migrations fail quietly — not with crashes or errors, but with subtle correctness bugs that only surface under real load with real users. By the time they appear, they are intermittent and hard to reproduce locally.

Workers are separate OS processes. They do not share RAM. Period. An object you put into a JavaScript Map in Worker 1 is completely invisible to Worker 2. They have separate V8 heaps, separate garbage collectors, separate everything. This fact ripples through almost every stateful pattern you might have built assuming single-process operation.

Sessions: User logs in on Worker 1. Session stored in Worker 1's heap. Next request round-robins to Worker 3. Worker 3 has no record of that session. User appears logged out. No error is emitted anywhere in the system — just a redirect to the login page. In a real application with user activity across many tabs, this produces a particularly confusing experience where the user appears to be constantly losing their session.

Rate limiting: You allow 100 requests per minute per user. In-memory counter in Worker 1 shows the user has made 12 requests. But Workers 2 through 8 each show 12 requests in their own independent counters. Real combined count: 96 requests that slipped through before any worker saw a limit breach. Your rate limiter is off by a factor of 8, precisely proportional to your worker count.

In-memory caches: Each worker builds its own cache from cold independently. You get N times the cache warming time, N times the memory usage for the same data, and N potentially inconsistent views of the cached data if any worker refreshes at a different time.

The fix is always the same: externalize state. Redis is the industry standard for this because it gives you sub-millisecond latency, native data structures that map directly to common patterns, atomic operations that eliminate race conditions, and TTL-based expiry. Each worker gets its own Redis client connection — this is idiomatic and correct, not wasteful. Redis handles tens of thousands of concurrent connections efficiently. Eight workers adding eight connections is not a concern worth spending time on.

const cluster = require('node:cluster');
const express = require('express');
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const { createClient } = require('redis');
const os = require('node:os');

if (cluster.isPrimary) {
  cluster.schedulingPolicy = cluster.SCHED_RR;
  os.cpus().forEach(() => cluster.fork());

  cluster.on('exit', (worker, code) => {
    if (!worker.exitedAfterDisconnect) {
      console.error(`Worker ${worker.id} crashed (code: ${code}). Replacing.`);
      // In a real implementation this would use the backoff logic
      // from the previous section — shown simplified here for clarity.
      cluster.fork();
    }
  });

} else {
  const app = express();

  // Each worker creates its own Redis client — this is correct.
  // Do NOT try to share a connection through the primary via IPC.
  // That pattern serializes all session operations through the primary
  // process (which should be doing nothing) and adds a round-trip
  // on every single session read. Redis is designed for exactly this
  // many-connections pattern.
  const redisClient = createClient({
    socket: {
      host: process.env.REDIS_HOST || '127.0.0.1',
      port: parseInt(process.env.REDIS_PORT || '6379', 10)
    }
  });

  redisClient.on('error', (err) => {
    console.error(`Worker ${process.pid} Redis error:`, err.message);
  });

  // If Redis is unreachable on startup, exit cleanly with a useful message.
  // The primary's exit handler will respawn — but with backoff, so a Redis
  // outage doesn't become a fork-bomb.
  redisClient.connect().catch((err) => {
    console.error(
      `Worker ${process.pid} could not connect to Redis at startup:`,
      err.message
    );
    process.exit(1);
  });

  app.use(
    session({
      store: new RedisStore({ client: redisClient }),
      secret: process.env.SESSION_SECRET,
      resave: false,
      saveUninitialized: false,
      cookie: {
        secure: process.env.NODE_ENV === 'production',
        httpOnly: true,
        sameSite: 'lax',
        maxAge: 24 * 60 * 60 * 1000 // 24 hours
      }
    })
  );

  app.get('/', (req, res) => {
    req.session.views = (req.session.views || 0) + 1;
    res.json({
      views: req.session.views,
      worker: process.pid,
      note: 'View count is consistent regardless of which worker handles the request'
    });
  });

  app.listen(3000, () => {
    console.log(`Worker ${process.pid} listening on port 3000`);
  });
}

Cluster vs Worker Threads: Choosing the Right Tool for the Job

These two APIs get conflated constantly — in technical articles, in job interviews, and in pull requests. The question 'cluster vs worker threads' is often framed as a competition where one wins. They do not compete. They solve different categories of problem at different layers of the same system.

Clustering multiplies your server's ability to handle concurrent connections. Each worker gets its own event loop. Eight workers means eight event loops running in parallel, each independently accepting and processing requests. This is purely a concurrency story — you are not making any individual operation faster, you are enabling more operations to run simultaneously. The requests are still I/O-bound. They still spend most of their time waiting on databases, external APIs, or filesystem operations.

worker_threads solves a different problem: CPU-intensive computation that would block the event loop if run on the main thread. Image resizing, parsing a 10 MB JSON document, computing bcrypt hashes, video transcoding, running ML inference — these operations occupy your event loop thread for their full duration. Every other request that arrives during that time waits. Worker threads let you move that computation to a separate thread within the same process. That thread shares the V8 heap but has its own execution context and does not block the event loop from accepting new requests.

The practical differences matter for production decisions. Cluster workers are full Node.js processes — 30 to 80 MB each, full startup time, full GC overhead. Worker threads are lightweight threads within an existing process — 2 to 4 MB each, fast startup, shared GC. But that shared heap cuts both ways: an unhandled exception in a worker thread can bring down the entire cluster worker process, not just the thread. When CPU work must be fully fault-isolated — a crash in the computation must not kill the request handler — child_process.fork() is actually the right call, not worker_threads. Full process isolation, higher overhead, but a crash in the child does not propagate to the parent.

In practice, high-traffic production Node.js services that handle both heavy concurrency and CPU-intensive per-request operations typically use both: clustering for the outer concurrency layer, and worker threads within each cluster worker for the CPU-bound tasks. This is a legitimate production architecture, not premature complexity.

const cluster = require('node:cluster');
const { Worker, isMainThread, parentPort, workerData } = require('node:worker_threads');
const http = require('node:http');
const os = require('node:os');

// This file serves three roles depending on how it is entered:
// 1. Primary process (cluster.isPrimary && isMainThread) — forks workers
// 2. Cluster worker (cluster.isWorker && isMainThread) — handles HTTP, spawns threads
// 3. Worker thread (!isMainThread) — does CPU-bound computation

if (cluster.isPrimary && isMainThread) {
  const coreCount = os.cpus().length;
  console.log(`Primary ${process.pid}: forking ${coreCount} cluster workers`);
  cluster.schedulingPolicy = cluster.SCHED_RR;
  for (let i = 0; i < coreCount; i++) cluster.fork();

  cluster.on('exit', (worker, code) => {
    if (!worker.exitedAfterDisconnect) {
      console.error(`Worker ${worker.id} died (code: ${code}). Replacing.`);
      cluster.fork();
    }
  });

} else if (isMainThread) {
  // Cluster worker: handles HTTP requests, offloads CPU work to threads.
  // The event loop here stays responsive because the heavy computation
  // runs in a thread, not on this thread.
  const server = http.createServer((req, res) => {
    if (req.url === '/compute') {
      // Spawn a worker thread for the CPU-bound task.
      // Each request gets its own thread here — for high-throughput scenarios
      // you would use a thread pool (Piscina is good for this) rather than
      // spawning a new thread per request.
      const thread = new Worker(__filename, {
        workerData: { iterations: 1_000_000_000 }
      });

      thread.once('message', (result) => {
        res.writeHead(200, { 'Content-Type': 'application/json' });
        res.end(JSON.stringify({ result, handledBy: process.pid }));
      });

      thread.once('error', (err) => {
        // Thread crash does not kill this cluster worker — but
        // we do need to handle it and respond to the client.
        console.error(`Thread error in worker ${process.pid}:`, err.message);
        res.writeHead(500);
        res.end(JSON.stringify({ error: err.message }));
      });

    } else {
      res.writeHead(200);
      res.end(`Cluster worker ${process.pid}`);
    }
  });

  server.listen(3000, () => {
    console.log(`Cluster worker ${process.pid} listening`);
  });

} else {
  // Worker thread: CPU-bound computation.
  // This runs in a thread, not a cluster worker.
  // The main thread's event loop is completely unaffected while this runs.
  let result = 0n;
  const limit = BigInt(workerData.iterations);
  for (let i = 0n; i < limit; i++) result += i;
  parentPort.postMessage(result.toString());
}

Debugging and Profiling Individual Workers in a Cluster

When something goes wrong in a clustered service, the debugging instinct is often to attach a debugger or take a heap snapshot at the application level. But a cluster is N independent processes, each with its own PID, its own event loop, its own memory, and its own debug port. The tools you use for single-process debugging need deliberate adaptation for this multi-process reality.

The --inspect flag cannot be shared across workers — each worker needs its own debug port. Node.js provides --inspect-port=0 to auto-assign a unique port per worker. When the primary is started with this flag, each forked worker gets its own port assigned from the OS's available port range. Node.js logs the assigned port when each worker comes online. You can then connect Chrome DevTools (chrome://inspect) or a VS Code debug session to any individual worker's port.

Heap snapshots follow the same logic. The kill -USR2 signal must be sent to a specific worker PID, not to the primary. Sending it to the primary captures the primary's heap, which contains only cluster management structures — not request-handling memory. If you configure v8.writeHeapSnapshot() in your worker code path, each worker will write its own snapshot file when it receives the signal, named with its PID for disambiguation.

For production environments where attaching a debugger is not practical, the most reliable approach is structured logging with process.pid on every log line, aggregated into a centralized log system. When a specific worker shows anomalous behavior — climbing memory, elevated error rates, slow response times — you can filter by PID in your log aggregator and reconstruct exactly what that worker was doing in the minutes before the problem appeared. This is faster and less disruptive than attaching an inspector to a live production process.

Exposing a per-worker /health endpoint that returns process.pid, process.uptime(), and process.memoryUsage() is something I add to every cluster implementation I ship. It costs almost nothing and it lets your load balancer health checks detect workers that are alive but degraded — a critical distinction that a simple TCP health check cannot make.

const cluster = require('node:cluster');
const http = require('node:http');
const os = require('node:os');

if (cluster.isPrimary) {
  const numCPUs = os.cpus().length;
  console.log(`Primary ${process.pid} forking ${numCPUs} workers`);
  console.log('Debug: node --inspect-port=0 inspect-workers.js');
  console.log('Each worker will log its auto-assigned debug port on startup.');

  cluster.schedulingPolicy = cluster.SCHED_RR;

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('online', (worker) => {
    console.log(`Worker ${worker.process.pid} came online`);
  });

  cluster.on('exit', (worker, code, signal) => {
    if (!worker.exitedAfterDisconnect) {
      console.error(
        `Worker ${worker.process.pid} died ` +
        `(code: ${code}, signal: ${signal}). Replacing.`
      );
      cluster.fork();
    }
  });

} else {
  const formatBytes = (bytes) => `${Math.round(bytes / 1024 / 1024)} MB`;

  const server = http.createServer((req, res) => {
    // Health endpoint — returns per-worker memory and uptime.
    // Your load balancer health checks should hit this, not just check TCP.
    // An OOM-pressured worker that responds slowly is worse than a dead
    // worker that gets replaced immediately.
    if (req.url === '/health') {
      const mem = process.memoryUsage();
      const payload = {
        status: 'ok',
        pid: process.pid,
        uptimeSeconds: Math.round(process.uptime()),
        memory: {
          rss: formatBytes(mem.rss),
          heapUsed: formatBytes(mem.heapUsed),
          heapTotal: formatBytes(mem.heapTotal),
          external: formatBytes(mem.external)
        }
      };
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(payload));
      return;
    }

    res.writeHead(200);
    res.end(`Worker ${process.pid}\n`);
  });

  server.listen(3000, () => {
    console.log(`Worker ${process.pid} listening — debug port auto-assigned if --inspect-port=0 was set`);
  });

  // Graceful shutdown
  process.on('SIGTERM', () => {
    server.close(() => process.exit(0));
    setTimeout(() => process.exit(0), 30_000).unref();
  });
}

Why Fork Mode Is the Only Realistic Strategy

The cluster module forks child processes. Each fork is a complete copy of the Node.js runtime. That means each worker has its own event loop, its own garbage collector, and its own memory space. You get true parallelism without shared memory headaches. The master process acts as a traffic cop: it receives all incoming connections and uses a round-robin scheduler (or platform-specific logic) to distribute them to idle workers. This is not threading. This is process-level isolation. If worker 3 crashes due to a memory leak, workers 1, 2, and 4 keep serving traffic. No lock contention. No race conditions. The price is higher memory per worker. You trade memory for fault isolation. In production, you always choose isolation over shared state. Always.

// io.thecodeforge
import cluster from 'node:cluster';
import http from 'node:http';
import { cpus } from 'node:os';

if (cluster.isPrimary) {
  const cpuCount = cpus().length;
  console.log(`Primary ${process.pid} forking ${cpuCount} workers`);

  for (let i = 0; i < cpuCount; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died. Forking replacement.`);
    cluster.fork();
  });
} else {
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('Hello from worker ' + process.pid);
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

Graceful Shutdown: Stop Dropping Requests on Deploy

A hard kill during deployment drops active connections. Users get 503s and your pager goes off. The fix is a graceful shutdown sequence. When the master receives a SIGTERM, it stops accepting new connections on the workers, drains existing requests, then exits. The master then forks a replacement worker. This is the zero-downtime pattern. You must listen for signal events on each worker, call server.close() to stop the listener, then wait for the active requests to finish. Use a timeout as a safety hatch: after 30 seconds, force kill. Never trust a slow request to finish. Ship a 'gracefulShutdown' helper. Wire it into your deployment pipeline. Test it with ab or wrk. If you haven't seen your app survive a rolling restart, you haven't deployed to production.

// io.thecodeforge
import cluster from 'node:cluster';
import http from 'node:http';

const SHUTDOWN_TIMEOUT = 30_000;

if (cluster.isPrimary) {
  cluster.on('message', (worker, msg) => {
    if (msg.type === 'shutdown-ready') {
      console.log(`Worker ${worker.process.pid} ready to shut down`);
      worker.kill();
    }
  });

  // Main app loop...
} else {
  const server = http.createServer((req, res) => {
    // Simulate long request
    setTimeout(() => res.end('ok'), 2000);
  }).listen(8000);

  const gracefulShutdown = () => {
    console.log('Shutting down gracefully...');
    server.close(() => {
      process.send?.({ type: 'shutdown-ready' });
    });

    setTimeout(() => {
      console.error('Forced shutdown after timeout');
      process.exit(1);
    }, SHUTDOWN_TIMEOUT);
  };

  process.on('SIGTERM', gracefulShutdown);
  process.on('SIGINT', gracefulShutdown);
}