Lately, I have been diving deep into the core architecture of Node.js. Like many developers, I spent months building servers, handling routes, and streaming responses with Express, taking the runtime’s asynchronous behavior almost entirely for granted. We all repeat the familiar talking points: “Node.js is single-threaded, non-blocking, and event-driven.” But what actually makes that true? If the JavaScript engine executing our code is strictly single-threaded, how does an HTTP server sustain tens of thousands of concurrent connections without freezing on the first database query or disk read?
The answer lies beneath the surface of the V8 engine. While Google’s V8 executes raw JavaScript bytecode with exceptional speed, it knows absolutely nothing about operating system sockets, network events, file system access, or thread pools. The entity bridging the gap between JavaScript’s single-threaded call stack and the host operating system is libuv a battle-tested, high-performance C library originally created specifically for Node.js.
The Anatomy of the Node.js Runtime
To understand the exact role libuv plays, we first need to look at how a Node.js process is assembled. When you boot up an application, the runtime orchestrates several independent C/C++ subsystems working in tandem beneath your JavaScript code.
