Node.js Runs a Single Threaded Event Loop That Offloads Work to libuv

One of the first things a new Node.js developer hears is that the runtime is single threaded. It is an idea that confuses people, because Node clearly handles thousands of concurrent connections without breaking a sweat. The truth is more subtle and more useful: Node runs your JavaScript on one main thread with a single event loop, but delegates the blocking work that JavaScript cannot do on its own to a hidden pool of worker threads provided by libuv.

libuv is the C library that gives Node its cross platform event loop and thread pool. When you call a function like fs.readFile or a database driver that touches the filesystem, Node does not let that operation stall the main thread. It hands the task to libuv, which dispatches it to a worker thread from its default pool of four, and registers a callback. When the operation completes, libuv queues the callback and the event loop runs it on the main thread as soon as the current turn is done.

This division of labour is what powers Node's concurrency. The event loop processes JavaScript quickly because it never blocks for the slow parts. Disk reads, socket writes, DNS lookups, these all run off to the thread pool and come back as callbacks or promises. That is why a busy web server can serve thousands of requests on a single process. The JavaScript code is not doing the waiting. The thread pool is, and the results are handed back in an orderly queue.

The practical lesson for a senior developer is to know which work uses the pool and which does not. CPU heavy work, JSON serialization of a huge payload, image resizing, tight cryptographic loops, runs entirely on your one event loop thread. If you block that thread, every request in the process grinds to a halt. I/O work is mostly free because it rides the pool. The distinction decides whether your service stays responsive under load or turns into a slow, unresponsive process at the worst possible moment.

You can tune the pool with the UV_THREADPOOL_SIZE environment variable, though defaults are rarely the bottleneck unless you are doing heavy filesystem or crypto work. The mistake is treating the thread pool as unlimited. It is a small, finite set of workers, and if you saturate it with slow calls, new I/O queues patiently behind them.

Understanding this architecture changes how you write code. You push heavy CPU work onto worker_threads or a queue and a separate process. You keep the event loop fast and the pool focused. When you internalize that Node is not one thread but a fast loop plus a small team of helpers, the framework makes sense, and you stop blaming Node for the ways a blocked loop can take down an entire API.