The event loop (overview)

Node's concurrency model is cooperative on a single main thread, backed by libuv thread pool and OS async I/O. Understanding the event loop explains why async code order surprises beginners and why blocking sync work hurts throughput.

Simplified phases

1. Run synchronous code — top to bottom until the call stack is empty
2. Microtasks — promise callbacks (.then, await continuations) run before the next macrotask
3. Macrotasks — setTimeout, setImmediate, I/O callbacks
4. Repeat — process pending work until the program exits

Classic ordering puzzle

console.log('A');
setTimeout(() => console.log('B'), 0);
Promise.resolve().then(() => console.log('C'));
console.log('D');
// A, D, C, B

Sync first, then microtasks (C), then timer (B).

What to avoid

Long synchronous loops, huge JSON parsing on hot paths, or sync fs.readFileSync under load block the loop—every other request waits. Prefer async APIs and offload CPU work to worker threads when needed.

Important interview questions and answers

1. Q: Is Node multi-threaded?
   A: JavaScript runs on one main thread; libuv and worker threads handle some I/O and CPU work behind the scenes—the model feels single-threaded to your JS code.
2. Q: Microtask vs macrotask?
   A: Promises run as microtasks before the next timer/I/O macrotask—explains why await resolves before setTimeout(fn, 0).
3. Q: When use worker_threads?
   A: CPU-intensive tasks (image processing, heavy crypto) that would starve the event loop on the main thread.

Self-check

1. In the puzzle above, why does C print before B?
2. What happens if you run a 30-second sync loop on the main thread during a request?

Tip: Draw the event loop as a queue: synchronous code runs first, then microtasks (promises), then macrotasks (timers). Blocking the main thread blocks everything.