The Event Loop and Asynchronous JavaScript in Node.js

The most important thing to understand about Node.js — and the reason it is excellent for REST APIs — is that it is single-threaded and non-blocking. A single Node.js process handles all incoming requests on one thread, never waiting idle for a database query or file read to finish. This is the event loop at work. Understanding the event loop is not just academic — it directly explains why your Express routes should never have synchronous blocking operations, why you must use async/await for database calls, and why your server can handle hundreds of concurrent requests without spawning hundreds of threads.

Single-Threaded vs Multi-Threaded Servers #

The Event Loop — Phase by Phase #

Node.js Event Loop — Simplified Phase Order
═══════════════════════════════════════════════

   ┌─────────────────────────┐
   │         timers          │  ← setTimeout / setInterval callbacks
   └──────────┬──────────────┘
              │
   ┌──────────▼──────────────┐
   │     pending callbacks   │  ← I/O callbacks deferred from previous loop
   └──────────┬──────────────┘
              │
   ┌──────────▼──────────────┐
   │      poll (I/O)         │  ← NEW I/O events: file reads, DB responses,
   │                         │    HTTP responses — THIS is where most of your
   │                         │    Express callbacks resume
   └──────────┬──────────────┘
              │
   ┌──────────▼──────────────┐
   │         check           │  ← setImmediate callbacks
   └──────────┬──────────────┘
              │
   ┌──────────▼──────────────┐
   │    close callbacks      │  ← socket.on('close', ...) etc.
   └──────────┬──────────────┘
              │
         loop repeats

Microtasks (Promises, process.nextTick) run BETWEEN every phase.

Blocking vs Non-Blocking — Side by Side #

// ── BLOCKING — never do this in an Express route ──────────────────────────────
const fs = require('fs');

app.get('/api/config', (req, res) => {
  // readFileSync blocks the ENTIRE event loop until the file is read
  // All other incoming requests are frozen during this time
  const data = fs.readFileSync('./config.json', 'utf8');
  res.json(JSON.parse(data));
});

// ── NON-BLOCKING — the correct way ───────────────────────────────────────────
const fs = require('fs/promises');

app.get('/api/config', async (req, res) => {
  // readFile is async — event loop continues handling other requests
  // while the OS reads the file in the background
  const data = await fs.readFile('./config.json', 'utf8');
  res.json(JSON.parse(data));
});

The Call Stack, Callback Queue, and Event Loop Together #

console.log('1 — synchronous, runs first');

setTimeout(() => {
  console.log('3 — setTimeout callback: runs after current stack clears');
}, 0);

Promise.resolve().then(() => {
  console.log('2.5 — microtask: runs before setTimeout, after synchronous code');
});

console.log('2 — synchronous, runs second');

// Output order:
// 1 — synchronous, runs first
// 2 — synchronous, runs second
// 2.5 — microtask: runs before setTimeout, after synchronous code
// 3 — setTimeout callback: runs after current stack clears

How This Applies to Your Express API #

// This is what happens when TWO requests arrive at the same time

// Request A: GET /api/posts
app.get('/api/posts', async (req, res) => {
  // 1. Mongoose sends query to MongoDB
  // 2. Node.js does NOT wait — event loop continues
  const posts = await Post.find();   // ← non-blocking I/O
  // 5. When MongoDB responds, event loop resumes HERE
  res.json({ data: posts });
});

// Request B arrives while Request A is awaiting Post.find()
app.get('/api/health', (req, res) => {
  // 3. Event loop picks up Request B immediately
  // 4. This responds instantly — no waiting for Request A's DB query
  res.json({ status: 'ok' });
});

// Result: Both requests are handled concurrently on ONE thread.
// Request B gets its response while Request A is still waiting for MongoDB.

Common Mistakes #

Mistake 1 — Using synchronous file/crypto operations in route handlers #

❌ Wrong — synchronous methods with Sync suffix block the event loop:

app.post('/api/auth/register', (req, res) => {
  const hash = bcrypt.hashSync(req.body.password, 12); // blocks for ~200ms
  // All other requests queue up behind this one
});

✅ Correct — use the async version:

app.post('/api/auth/register', async (req, res) => {
  const hash = await bcrypt.hash(req.body.password, 12); // non-blocking ✓
});

Mistake 2 — Large synchronous loops in route handlers #

❌ Wrong — processing a large array synchronously blocks all other requests:

app.get('/api/report', (req, res) => {
  const result = hugeArray.map(item => expensiveTransform(item)); // blocks!
  res.json(result);
});

✅ Correct — offload to a Worker Thread or a background job queue (Bull/BullMQ) for CPU-heavy processing.

Mistake 3 — Assuming async functions run in parallel automatically #

❌ Wrong — awaiting two independent queries sequentially when they could run in parallel:

const posts = await Post.find();    // waits 50ms
const users = await User.find();    // then waits another 50ms = 100ms total

✅ Correct — use Promise.all() to run independent async operations concurrently:

const [posts, users] = await Promise.all([Post.find(), User.find()]); // ~50ms total ✓

Quick Reference #