I think there is some confusion/conflation with "blocking IO" and "blocking the event loop". If some requests are more computationally intensive than others, y

I think there is some confusion/conflation with "blocking IO" and "blocking the event loop". If some requests are more computationally intensive than others, you will see slower response times for the less computationally intensive requests. This is similar to the classic "queueing" problem with some load balancing algorithms, where a fast request can get queued up behind a slow request on one worker process, only to miss out on another worker process becoming available. Even if you load balance with node, each node is processing multiple requests so you can still have this problem. One thing to note is that it's not inefficient. You will be maximizing your CPU's and will be processing work as efficiently as possible, but users will experience some requests having a variable response time. This can happen any time you have a pool of generalized worker processes btw, it's not just a "node thing". Solutions? If some requests do significantly more computation than others, you can split the computation in half using process.nextTick(). This will let smaller requests go faster in exchange for the slower request going slower (remember, we're already at max efficiency, so it's not like everything is going to get faster). This is better than sending the work out to a separate process unless the job is so big that the serialization/IPC cost is negligible. Otherwise you're adding extra work and making everything slower. But really, having to manually chop up your algorithms is kind of a special case. Most requests in your app probably take the same order of magnitude in terms of computation time, or they are obvious outliers (pdf generation, video encoding, etc) that you would want to move to a separate process.