Node's cluster module, when a connection comes in, how does it actually decide which worker gets it?
A strong answer follows a connection from accept to worker under both scheduling modes, and can say why long-lived connections defeat round-robin.
Cluster forks a bunch of Node processes that cooperate so one port serves all of them. With the default scheduling policy, which is round-robin, the primary process accepts the incoming connections and hands them out to workers in turn, so the load stays roughly even. On Windows the default is different, the OS decides which process gets each connection there. Every worker runs your full server code. For long-lived stateful protocols like WebSockets, or Socket.IO holding session state, you need sticky sessions, meaning the same client always lands on the same worker, and round-robin doesn't guarantee that, so you add affinity at a proxy or hash by client address or something like that. There's also SO_REUSEPORT as an alternative to the whole arrangement, where each worker opens its own listening socket and the kernel spreads the connections between them.