Node.js Event Loop

What is the event loop?

Imagine a restaurant where there is only one chef. If that chef had to stand by the oven and watch every dish cook, the whole kitchen would grind to a halt. Instead, the chef puts a dish in the oven, sets a timer, and moves on to other tasks. When the timer rings, the chef checks in. That is exactly what Node.js does.

Node.js runs your JavaScript on a single thread - there is only one chef in the kitchen. But it handles thousands of tasks concurrently using the event loop, an internal mechanism that keeps checking: "Is anything ready for me to handle next?"

The phases of the event loop

The event loop cycles through six distinct phases, in order, on every tick:

1. Timers - Runs callbacks scheduled by setTimeout() and setInterval() whose delay has elapsed.
2. Pending callbacks - Handles I/O errors and other deferred callbacks from the previous cycle.
3. Idle, prepare - Internal bookkeeping. You will rarely think about this phase.
4. Poll - The heart of the loop. Waits for new I/O events (file reads, network responses) and executes their callbacks.
5. Check - Runs callbacks registered with setImmediate().
6. Close callbacks - Cleans up closed connections and socketsSocketThe live, two-way connection between one specific client and a server. A port routes traffic to a process; a socket is the individual, ongoing conversation happening on top of that port..

Microtasks vs macrotasks

This is the part that trips up most developers.

Microtasks run immediately after the current operation finishes, before the event loop moves to its next phase. Resolved Promise callbacks and queueMicrotask() calls fall here.

Macrotasks (also called timers or I/O callbacks) go into one of the phases above and are processed in their turn.

The classic way to see this is a four-line script whose output order surprises almost everyone the first time. Step through it in the order Node actually executes it, not the order it's written:

1console.log("1 - synchronous");2setTimeout(() => console.log("2 - macrotask (timer)"), 0);3Promise.resolve().then(() => console.log("3 - microtask"));4console.log("4 - synchronous");

Notice how the promise callback (3) runs before the timer (2), even though the timer delay is zero. The microtask queue is drained completely before the loop advances.

Why does this matter in practice?

BlockingBlockingA function call that stops all other work until it finishes - like a phone call where you wait in silence for an answer. The opposite of non-blocking, where you start the work and move on immediately. the loop is the one mistake that takes down everything else at once. Run a CPU-heavy calculation synchronously - sorting a million records, hashing a large payload - and you freeze the single thread every request depends on. It's not that one request gets slow. Every request queued behind it gets slow, including ones that had nothing to do with the expensive work.

A few ways this sneaks in without anyone noticing at first:

• JSON.parse() on a genuinely large string, synchronously, inside a request handler
• fs.readFileSync() used because it was faster to write and nobody circled back
• A recursive algorithm that runs to completion in one tick instead of yielding partway through

The fix is always some version of "get this off the main thread" - a Worker Thread for CPU work (next topic), or a background job queue if it doesn't need to block the response at all.

Mental model to keep

The event loop isn't smart. It's a very fast, very literal loop: check timers, check I/O callbacks, drain every pending microtask, repeat. Nothing about it schedules based on priority or fairness - it just keeps cycling through the same phases in the same order, as fast as it can.

Which means the loop's speed is entirely a function of how fast your callbacks return control. Keep them short and non-blocking, and the loop barely notices load. Block it even once, and that cost gets paid by every single thing waiting behind it - not proportionally, but all at once.