Role of libuv in the Node.js runtime

WHAT THIS TESTS This checks whether the candidate understands the layered architecture of Node and can distinguish the JavaScript engine from the runtime that surrounds it. It reveals depth beyond surface-level async/await usage.

A GOOD ANSWER COVERS V8 only compiles and executes JavaScript; it knows nothing about timers, sockets, or files. libuv is the C library that supplies these capabilities. It runs the event loop, the central dispatcher that processes callbacks in well-defined phases. For network I/O it uses the operating system's native async mechanisms: epoll on Linux, kqueue on macOS and BSD, and IOCP on Windows. These let one thread watch many sockets without blocking. For operations the kernel cannot do asynchronously, such as most filesystem calls, DNS lookups via getaddrinfo, and some crypto, libuv uses a worker thread pool (default four threads). The blocking call runs on a pool thread, and when it completes the result is queued back to the main loop, which invokes the JavaScript callback on the single main thread.

COMMON WRONG ANSWERS Saying V8 provides the event loop. Saying Node is purely single-threaded; the JS execution is single-threaded but libuv uses multiple threads underneath. Assuming all async work uses the thread pool, when in fact network sockets use OS polling, not threads.

LIKELY FOLLOW-UPS What is UV_THREADPOOL_SIZE and when would you raise it? Why is filesystem I/O on the pool but TCP is not? What are the event loop phases? How can a slow synchronous callback still block everything?

ONE CONCRETE EXAMPLE Reading ten files concurrently with fs.readFile dispatches the reads to libuv's thread pool. With the default size of four, only four run at once and the rest queue. Hashing many large buffers with crypto can saturate the same pool and starve unrelated file reads, which is why tuning UV_THREADPOOL_SIZE matters under load.