We still don’t really get what happens when we call a system-level API.
Like, when you run fs.readFileSync() in Node.js. You’re not just calling a cute little JS function.
That line drops into V8 → dives through C++ → tunnels through libuv → and punches the kernel with a system call.
And that whole journey?
It’s where the real magic of computing happens, yet most developers feel it's a black box.
It’s the part we all rely on but rarely understand.
And honestly?
That’s wild.
To break it down for you, I will cover a high-level summary of the following rarely explored topics:
- System Architecture Layers: how operations are actually executed by the computer/operating system/ programming language.
- Node.js internals: libuv and the event loop
- Browser engine internals: how the fetch API, for example, interacts with lower-level systems
- libuv and async I/O: how this maps system calls
- Performance and mental models: How system-level knowledge helps avoid performance pitfalls and build mental models.
While you dive deep into this stuff, CodeRabbit has your back at a higher level. It catches bugs, suggests improvements, and helps you keep your code clean and consistent, all in real time.
You can focus on learning and shipping. CodeRabbit handles the nitty-gritty.
Now, Let's break down the black box!
System Architecture Layers
The system architecture of Linux OS is largely composed of elements such as the Hardware layer, Kernel layer, System libraries, System Utilities, and User Applications.
Hardware Layer: This sets the foundation of the Linux architecture, it consists of all the device drivers required for system operations, such as memory, CPU, storage devices, and network interfaces.
Kernel Layer: This is the core of the Linux OS, it provides an interface that directly communicates with hardware and manages essential system resources. The kernel includes the following components, process management, memory management, device drivers, file system management and network management.
System Libraries: System libraries provide the methods that applications used by a user can interact with the kernel. These libraries, like the GNU C lIBRARY( glibc) provide a simple way to interact with kernel operations.
System Utilities: This consists of utilities like basic utilities and advanced utilities, they are programs that help with system administration and maintenance tasks. A good example is when you use the cp command to copy files, and an advanced utility is when you use tools like ps , top for more complex system tasks.
The following illustration is a real-world example of a user operation in Linux (copying a file) to show how these layers work together:
In the above image, the hardware layer shows the CPU, memory, and disk drive that interact and execute the copy operation. The user applications are where a GUI is used to copy files or a cp command in the background to complete a task.
Node.js Internals
In the Node.js first presentation at JSConf 2009 by Ryan Dahl, the theme was “I/O needs to be done differently”. Ryan opened his talk with an illustration of a basic example from a server application code:
const result = db.query('SELECT * FROM table');
// Do something with the result
His question was: “What is your web framework doing while this line of code is running?”
In many cases, the execution thread pauses until it gets a response. Considering how long various operations take, A single file operation can put to waste millions of cycles.
Node.js handles I/O operations (Input and Output) using it’s event-driven, non-blocking architecture. The illustration below shows two types of operations, on the left side is a normal traditional blocking I/O and on the right side is the Node.js event loop and non-blocking I/O.
It shows the event loop, which is the central coordinator, the libuv Thread Pool that handles blocking tasks i.e the file system operations, the Callback Queue where completed async tasks wait to be executed and the Main Thread that runs Javascript and responds to events as they complete.
The illustration clearly shows how Node.js scale better with I/O intensive operations compared to traditional blocking like Apache. When you think of Apache for example:
- Each incoming request triggers a new process
- Threads will pause until database queries or file operations are completed.
- Has high memory usage and frequent context switching
- Not suitable when dealing with many concurrent requests.
While Node.js offers
- A single main thread handles all incoming requests, and continues to process other requests without blocking.
- Database queries or file operations are delegated to a background thread pool, and when operations are completed, callbacks are lined up for firing via the event loop.
Browser engine internals
The browser engines provides a Fetch API that is based on the Promise API. It provides a consistent and elegant way to handle asynchronous operations in a Node application. When you call the fetch() function, it returns a Promise object that fulfills with a Response object if the operation is a success, or throws an error if the request fails.
In a mystical way, the Fetch API uses the XMLHttpRequest object to ping the server with HTTP requests and get responses. The XMLHttpRequest is the hero under the hood here, and has been around since the early days of the web.
From the illustration above, when you call fetch(), the browse’s JS engine will create a new XMLHttpRequest which is the internal Fetch API implementation inside the browser’s native layer.
This API takes any provided listeners like method, headers and handles the low-level operations like DNS resolutions, and socket communication.
When the server sends back a response or an error, the browser creates a Response object and resolves the Promise that fetch() initially initiated (the point where the .then or await logic in JS executes.
libuv and async I/O: how this maps system calls
On Unix-like systems (Linux/macOS), libuv uses a thread pool to execute system calls such as read() , write(), open(), and close() without pausing the main thread.
While for Network operations (Sockets), libuv uses OS-level async I/O structures. Libuv also handles timers (setTimeout, setInterval) behind the hood using a priority queue and compares the disparities on each recursion.
libuv uses the event loop to prevent non-blocking I/O operations without pausing the execution of other code.
Some examples of events are:
- File is ready for writing
- A socket has data ready to be read
- A timer has timed out
As we have already discussed the event loop above here, Libuv provides a portable, and powerful event loop by placing async I/O in Javascript to the low level constructs like epoll on Linux, kqueue for macOS and Windows on IOCP for completion ports.
Mental Models and Performance
So far, we have some knowledge on the execution model of I/O and how Node.js utilizes libuv to manage asynchronous tasks without blocking the main thread.
Now, you are in a situation where you need to block the thread, like when you are building a CLI tool or script where it is simpler and no concurrency worries.
When you are building a server and everything runs once before initialization, or when you are writing a test suite and synchronous code is easier to mock.
The illustration below visually displays how fs.readFileSync() in Node.js interacts with the system.
The illustration above might look simple, but it is a synchronous API, meaning it blocks the operation until the file is read and should be avoided when building I/O heavy applications. When you call fs.readFileSync it internally executes to C++ and provides a binding object through node_file.cc in the Node’s C++ layer.
binding.read(fd, buffer, offset, length, position);
Next, libuv will directly execute a system call since this is a sync version, and this will end up calling the actual OS syscall.
On Linux, this is an explicit transition from user space to kernel space through the read syscall. The OS copies data from the file (disk or cache) to your buffer in memory. Your process is blocked during this time.
When the syscall completes, the buffer is filled in, the C++ layer marshals it into a Buffer object, and V8 exposes it to your JavaScript.
That one-liner JS code translates to:
- Crossing language boundaries (JS → C++)
- Avoiding async patterns
- Involving CPU context switching
- Blocking the main thread
How to Do Better?
In this case, systems knowledge will help you to know that libuv and the OS are perfect for handling low-level I/O operations since they keep you in control or give you the ability to predict performance behavior. Now, you can make a better design decision by ensuring that:
- You pick
fs.readFile()or evenfs.promises.readFile()in real applications that will have multiple requests. - Understand when you need to block operations in Node’s main thread
- Be in the loop of where your code will hand off control to the OS, libuv, etc.
How to Catch performance issues like this?
Understanding the mental model behind fs.readFileSync() and system calls gives you some knowledge and power.
But you don’t have to skim through every line of code yourself.
At CodeRabbit, we will help you catch blocking calls, scattered patterns, and bugs before they hit production.
Whether it's a rogue readFileSync() or a blocking fetch, CodeRabbit reviews your code with deep system awareness.
Wrapping Up
We have simplified some of the workings of the OS, and the relationship it has with the kernel, user space and syscalls. The top takeaways here are:
- The Linux kernel exposes services to programs via syscalls, which are functions that allow a program to interact with system resources.
- Synchronous = Blocking,
fs.readFileSyncblocks the main thread until the file is fully read, and in this period, all other operations are blocked. - System Layers: JavaScript code goes through transitions ( JavaScript ➡️ Node.js C++ bindings ➡️ libuv ➡️ System call ➡️ Disk) and each uses more memory, which increases the cost of blocking operations.
A single sync line of code blocks the whole system until the disk responds in Node.js, which is not ideal for intensive I/O applications.
That's it!
Hope you found this blog Helpful. If so, Feel Free to share this with your Peers!
Follow CodeRabbit for more content like this.
Share your thoughts in the comment section below! 👇
Thank you so much for reading! 🎉
Top comments (2)
Great Write-up
Thanks for checking out