libuv & Thread Pool
libuv is a C library that provides Node.js with cross-platform asynchronous I/O, a thread pool, timers, and the event loop implementation. It abstracts OS differences (epoll, kqueue, IOCP) behind a uniform API.
libuv is the backstage crew at a theater. Network I/O is like the lighting board (one person handles all lights). File I/O is like moving heavy sets—you need actual stagehands (threads), and you only have 4 by default.
libuv provides two mechanisms for async work: (1) OS-native async I/O (via epoll/kqueue/IOCP) for network sockets—no threads required; (2) a thread pool (default 4 threads) for operations that lack async OS support, including file system operations, DNS lookups (getaddrinfo), and certain crypto functions. You can tune pool size with the UV_THREADPOOL_SIZE environment variable (max 1024).
Network I/O in libuv is handled by the I/O watcher, which uses platform-native event notification (Linux epoll, macOS kqueue, Windows IOCP). These are truly non-blocking: a single thread can monitor thousands of sockets. File I/O is fundamentally different—POSIX async file I/O (aio_read) is poorly supported and inconsistent, so libuv uses blocking calls on worker threads and signals completion to the event loop via a pipe/eventfd. This means concurrent file operations compete for the same 4 thread pool slots as bcrypt, getaddrinfo, and any native addon that calls uv_queue_work. Increasing UV_THREADPOOL_SIZE to match I/O + crypto concurrency requirements is a standard production optimization.
libuv is Node's cross-platform async I/O layer. For network sockets it uses OS-native async notification (epoll/kqueue/IOCP) with zero threads. For file I/O and CPU-heavy crypto it uses a thread pool (default 4 threads, tunable via UV_THREADPOOL_SIZE). Understanding the distinction matters because saturating the thread pool with bcrypt hashes will delay unrelated file system operations.
Candidates assume 'non-blocking I/O' means no threads are used. In reality, fs.readFile blocks a libuv thread pool thread. Under high concurrent file I/O load, setting UV_THREADPOOL_SIZE=1 (or leaving it at 4) creates a bottleneck that manifests as slow network responses—a subtle and hard-to-diagnose production issue.