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 do