Surviving Node.js Clusters: Graceful Teardowns, Windows Quirks, and Black-Box Testing

When I set out to build Torus, a reverse proxy in Node.js, the node:cluster module looked like the perfect solution to my biggest architectural hurdle. Because Node.js is natively single-threaded, this core module is the standard way to achieve multi-core scaling - it lets a single application spawn multiple worker processes that all share the same server port. It solved the problem immediately. But it quietly introduced a serious vulnerability I didn't catch until it was almost too late. The Trap: Blind Resurrection After scaffolding the cluster, I wrote the standard if (cluster.isPrimary) block, looped through CPU cores, called cluster.fork(), and attached an exit listener to respawn workers on crash: cluster.on('exit', (worker, code, signal) => { logger.warn(`Worker ${worker.process.pid} died. Booting a replacement...`); cluster.fork(); }); On the surface, this is exactly right. If a worker blows up with an Out-Of-Memory exception or a rogue regex tears down the V8 engine, the Ma