Node.js Under the Hood: How the Event Loop Really Works (Beyond Just Call Stack and Callbacks)

Introduction

Most Node.js developers know the “Event Loop” is what makes Node.js non-blocking—but few truly understand how it orchestrates asynchronous operations under the hood.

After debugging production performance issues and analyzing Libuv’s C++ source code, I’ll show you:
✅ What really happens in each Event Loop phase (not just “callbacks go to the queue”)
✅ How Node.js handles 10,000+ concurrent connections efficiently
✅ Common misconceptions that lead to performance bottlenecks

Let’s dive deeper than any tutorial you’ve seen.

---

1. The Big Picture: Node.js Runtime Architecture

Node.js isn’t just JavaScript—it’s a multi-layered system:

┌───────────────────────────┐  
│         Your Code         │  (JavaScript)  
└─────────────┬─────────────┘  
              │  
┌─────────────▼─────────────┐  
│    V8 Engine (JavaScript) │  (Call Stack, Heap)  
└─────────────┬─────────────┘  
              │  
┌─────────────▼─────────────┐  
│   Node.js Bindings (C++)  │  (fs, http, crypto)  
└─────────────┬─────────────┘  
              │  
┌─────────────▼─────────────┐  
│      Libuv (Event Loop)   │  (Thread Pool, I/O Polling)  
└───────────────────────────┘  

Key Insight:

• V8 executes your JS code.
• Libuv (written in C) handles async I/O via the Event Loop.
• Thread Pool (default: 4 threads) offloads heavy tasks like file I/O.

---

2. The 6 Phases of the Event Loop (Libuv’s Secret Sauce)

The Event Loop isn’t a single queue—it’s 6 distinct phases, each with its own FIFO queue:

// Simplified Libuv event loop order (from libuv/src/unix/core.c)  
while (uv_loop_alive(loop)) {  
  uv__update_time(loop);  
  uv__run_timers(loop);        // Phase 1: Timers (setTimeout, setInterval)  
  uv__run_pending(loop);       // Phase 2: Pending I/O Callbacks  
  uv__run_idle(loop);          // Phase 3: Idle Handlers (rarely used)  
  uv__run_prepare(loop);       // Phase 4: Prepare Phase  
  uv__io_poll(loop, timeout);  // Phase 5: I/O Polling (epoll/kqueue)  
  uv__run_check(loop);         // Phase 6: Check Phase (setImmediate)  
  uv__run_closing_handles(loop);  
}  

Phase 1: Timers

• Executes setTimeout() and setInterval() callbacks.
• Gotcha: Timers aren’t guaranteed to run exactly on time—they depend on the loop’s workload.

Phase 2: Pending I/O Callbacks

• Runs callbacks from completed system operations (e.g., TCP errors).

Phase 5: I/O Polling (Most Important!)

• Where Node.js waits for new I/O events (HTTP requests, file reads).
• Uses epoll (Linux) or kqueue (macOS) for efficiency.
• Blocking until either:
• I/O events are detected, OR
• The next timer’s threshold is reached.

Phase 6: Check Phase

• Executes setImmediate() callbacks.
• Key Difference vs Timers:

  setTimeout(() => console.log('Timer'), 0);  
  setImmediate(() => console.log('Immediate'));  
  // Which runs first? Depends on the I/O phase!  

---

3. Thread Pool vs Event Loop: Who Does What?

Task	Executed In	Why?
fs.readFile()	Thread Pool	File I/O is blocking at OS level
http.request()	Event Loop (epoll)	Network I/O is non-blocking
crypto.pbkdf2()	Thread Pool	CPU-heavy task

Proof:

const start = Date.now();  
setTimeout(() => console.log('Timer 1'), 0);  
setImmediate(() => console.log('Immediate 1'));  
fs.readFile('bigfile.txt', () => {  
  console.log('File I/O Done');  
  setTimeout(() => console.log('Timer 2'), 0);  
  setImmediate(() => console.log('Immediate 2'));  
});  
// Output order? Try it!  

---

4. Common Performance Pitfalls (And Fixes)

Blocking the Event Loop

// Sync function in an Express route  
app.get('/', (req, res) => {  
  const data = fs.readFileSync('bigfile.txt'); // Blocks the loop!  
  res.send(data);  
});  

Fix: Always use async I/O.

Starving the Event Loop

// CPU-bound task blocks timers  
function hashPassword(password) {  
  let hash = password;  
  for (let i = 0; i < 1_000_000; i++) {  
    hash = crypto.createHash('sha256').update(hash).digest('hex');  
  }  
  return hash;  
}  

Fix: Offload to Worker Threads or split into chunks.

Timer Overload

// Thousands of timers cause memory leaks  
for (let i = 0; i < 10_000; i++) {  
  setTimeout(() => {}, 60_000);  
}  

Fix: Use setInterval() or timeouts pools.

---

5. Debugging the Event Loop Like a Pro

1. Check Event Loop Lag

let last = Date.now();  
setInterval(() => {  
  const now = Date.now();  
  console.log('Loop delay:', now - last - 1000, 'ms');  
  last = now;  
}, 1000);  

• >10ms delay? You’re blocking the loop.

2. Profile with Clinic.js

npx clinic flame -- node server.js  

Generates flamegraphs to spot bottlenecks.

3. Monitor Libuv Metrics

const { uv } = process.binding('uv');  
console.log('Pending handles:', uv.active_handles);  

---

Conclusion

Mastering the Event Loop means:
✅ Writing non-blocking code intentionally
✅ Debugging performance issues faster
✅ Architecting scalable Node.js apps

🚀 Challenge:
Run the code snippets above and observe their behavior. Spot any surprises? Share in the comments!

---

Thoughts? How have you battled Event Loop issues? Let’s discuss below! 👇