Node.js Architecture
Node.js architecture describes the parts inside Node.js and how they work together. Understanding these parts explains why Node.js handles thousands of users with very little memory.
The Big Picture
Node.js sits between your JavaScript code and the computer. It uses several building blocks to read files, talk to networks, and run your instructions.
+------------------------------------------+ | Your JavaScript Code | +------------------------------------------+ | Node.js Core Modules (fs, http) | +------------------------------------------+ | Node.js C++ Bindings | +--------------------+---------------------+ | V8 Engine | libuv | | (runs JavaScript) | (handles async work)| +--------------------+---------------------+ | Operating System and Hardware | +------------------------------------------+
The Main Building Blocks
V8 Engine
Google created V8 for the Chrome browser. V8 reads JavaScript and converts it into machine code. Node.js borrows V8 to run your programs outside the browser.
libuv
The libuv library manages tasks that take time, such as reading files or waiting for a network reply. It owns the event loop and a small group of helper workers called the thread pool.
C++ Bindings
Bindings connect JavaScript code with the C++ code underneath. When you call a function like fs.readFile, a binding passes your request to the system.
Core Modules
Core modules ship with Node.js. The fs, http, and path modules belong to this group. You load them with require or import.
Single Thread Explained
A thread is a worker that follows instructions one by one. Node.js runs your JavaScript on one main thread. One worker handles all your code.
Picture a restaurant with one waiter and a busy kitchen. The waiter takes an order and hands it to the kitchen. The waiter does not wait at the kitchen door. The waiter moves to the next table and serves the dish when the kitchen signals it is ready.
Customer 1 ----+
Customer 2 ----+--> [ One Waiter ] --> [ Kitchen Helpers ]
Customer 3 ----+ (Main thread) (Thread pool)
^ |
+---- Dish ready ----+
Blocking and Non-Blocking Work
Blocking Work
Blocking work stops the main thread until the task ends. A long calculation blocks every other user.
Non-Blocking Work
Non-blocking work starts a task and moves on. Node.js uses this style for files, databases, and networks.
const fs = require("fs");
console.log("Start");
fs.readFile("notes.txt", "utf8", (err, data) => {
console.log("File content:", data);
});
console.log("End");The output order is Start, End, and then the file content. The read request goes to libuv, and the main thread continues with the next line.
The Request Journey
A web request follows a clear path inside Node.js. Each step has one owner.
Browser request
|
v
Event Queue (requests wait in line)
|
v
Event Loop (picks one request at a time)
|
+--> Simple task? Main thread answers right away.
|
+--> Slow task? Thread pool works on it.
|
v
Callback returns the result
|
v
Response goes back to the browser
Strengths of This Design
- Low memory use, since one thread serves many users.
- Fast response for input and output tasks such as APIs and chat apps.
- Simple code, since you avoid locks and shared memory problems.
Limits of This Design
Heavy calculations hurt Node.js. Video conversion, image processing, and large math loops keep the waiter busy, so other customers wait. Worker threads and the cluster module solve this problem in later lessons.
Quick Summary
- V8 runs your JavaScript.
- libuv handles slow tasks in the background.
- One main thread runs your code.
- The event loop sends finished results back to your callbacks.
Keep the restaurant picture in mind. It explains most Node.js behavior you will meet.
