Node.js Internals — The Complete Guide

Chapter 1

First, forget Node.js.
Imagine a restaurant.

Before we talk about threads, event loops, or libuv — let's talk about a waiter.

But a smartwaiter does something different. He takes Table 1's order, hands it to the kitchen, and immediately goes to Table 2. Then Table 3. Then Table 4. The kitchen is doing the actual cooking — the waiter is just shuttling information. When the kitchen rings the bell, the waiter picks up the plate and delivers it. One waiter. Six happy tables. No waiting.

Let's simulate this right now. Click "New Customer" to add tables and watch the waiter handle all of them without freezing.

See that? The waiter isn't waiting at any table. He fires off each order and loops around. The kitchen is handling the "slow parts." This is exactly how Node.js works.

Chapter 2

"Single threaded" doesn't mean what you think

The confusion comes from not knowing which partis single threaded. Let's break Node.js into its actual layers:

The Event Loop's phases — click each one

The event loop isn't just "a loop." It has 6 distinct phases it cycles through continuously. Click each phase to understand what it does:

Chapter 3

What actually happens with 100,000 simultaneous requests?

Let's trace exactly what happens, step by step:

Hit the button below to watch this happen in slow motion:

Chapter 4

What happens when you read a large file?

Here's the complete journey of a file read request:

Notice: the thread that reads the file is blocked for the entire 800ms. But that thread is not your main JavaScript thread. It's one of libuv's 4 worker threads. Your event loop keeps spinning freely the whole time.

fs.readFile vs fs.createReadStream

fs.readFile('big.zip', (err, data) => {
  // data = entire 500MB Buffer
  // NOW you can process it
});

const stream = fs.createReadStream('big.zip');
stream.on('data', chunk => {
  // chunk = 64KB at a time
  // process, then ask for next
});

Chapter 5

What if all 4 thread pool threads are busy?

Let's see the thread pool live. The 4 boxes below are your libuv threads. Hit the buttons to queue work and watch what happens when they're all occupied:

What uses the thread pool vs what uses the OS directly?

This distinction matters enormously. Your Node HTTP server can handle 10,000 simultaneous outbound API calls without touching the thread pool at all. The OS handles those. Only file I/O and crypto compete for your 4 threads.

Chapter 6

The real enemy: blocking the event loop

They all freeze. Every single one. No request gets a response until that loop finishes. This is Node's actual Achilles heel — not the thread pool, not the single thread doing async — but synchronous code that runs too long.

Let's prove it. Hit "Block the loop" and watch:

Common ways developers accidentally block the event loop

const data = JSON.parse(req.body); // 10MB JSON = ~200ms of blocking

const file = fs.readFileSync('big.log'); // blocks for the entire read duration

app.get('/calc', (req, res) => {
  let sum = 0;
  for (let i = 0; i < 1e9; i++) sum += i; // blocks for seconds
  res.json({ sum });
});

const hash = crypto.pbkdf2Sync(pw, salt, 100000, 64, 'sha512'); // BLOCKS

The fix: Worker Threads for CPU-heavy work

If you genuinely need heavy computation, use a Worker Thread. It runs in a real parallel OS thread — completely separate from your event loop:

// main.js
const { Worker } = require('worker_threads');

app.get('/heavy', (req, res) => {
  const worker = new Worker('./heavy-compute.js', {
    workerData: { input: req.query.data }
  });
  worker.on('message', result => res.json(result));
  // Event loop is FREE while worker computes
});

// heavy-compute.js
const { workerData, parentPort } = require('worker_threads');
// This runs in a SEPARATE thread — blocking here is fine
const result = doHeavyComputation(workerData.input);
parentPort.postMessage(result);

Chapter 7

Handling ZIP files the right way

There are four approaches, from worst to best:

const buf = fs.readFileSync('upload.zip');  // BLOCKS event loop
const files = unzipSync(buf);               // BLOCKS event loop again
// All other users frozen during both operations

fs.readFile('upload.zip', (err, buf) => {
  // readFile is async — good!
  // But 'buf' is still 2GB in RAM — bad!
  // And unzip processing blocks the loop
  const files = unzipAllAtOnce(buf); // blocks!
});

const unzipper = require('unzipper');

fs.createReadStream('upload.zip')
  .pipe(unzipper.Parse())
  .on('entry', entry => {
    // entry is a stream — process 64KB at a time
    entry.pipe(fs.createWriteStream(`./out/${entry.path}`));
  });
// RAM stays flat. Event loop stays free.

// Streaming handles I/O (no RAM spike, no thread pool blocking)
// Worker Thread handles CPU validation (no event loop blocking)
const worker = new Worker('./zip-validator.js');
const stream = fs.createReadStream('upload.zip');

stream.pipe(unzipper.Parse()).on('entry', entry => {
  worker.postMessage({ path: entry.path, size: entry.vars.uncompressedSize });
  entry.pipe(fs.createWriteStream(`./out/${entry.path}`));
});
// Perfect. Nothing blocks. RAM stays low. All users happy.

Why streaming is the universal answer

Streaming means: process data in small chunks (usually 64KB) as it arrives, instead of waiting for all of it. The benefits stack up: