How to Understand the Node.js Event Loop

Node.js runs all JavaScript on a single thread. This means only one operation can execute at a time. The Event Loop is the mechanism that allows Node.js to handle thousands of concurrent operations despite this single thread by delegating work and resuming execution when results are ready.

The Event Loop runs in a continuous cycle with six distinct phases. These phases are timers, pending callbacks, idle and prepare, poll, check, and close callbacks. Each phase has a queue of callbacks to execute. The loop moves through these phases in order, executing all queued callbacks in each phase before moving to the next.

The timers phase executes callbacks scheduled by setTimeout and setInterval whose delay threshold has been reached. If you call setTimeout with a delay of 100 milliseconds, the callback becomes eligible to run in this phase once at least 100 milliseconds have passed. The operating system determines the actual timing, so delays are minimum guarantees, not exact times.

The poll phase is the most important phase for I/O operations. It retrieves new I/O events from the operating system and executes their callbacks. When Node.js is idle and waiting for I/O, the Event Loop blocks here waiting for the operating system to signal that data is ready, such as a database response or a file being read.

The check phase runs callbacks registered with setImmediate. These always execute after the poll phase completes, even if there are timer callbacks waiting. If you need a callback to run after the current poll phase but before any timers, use setImmediate. This makes setImmediate predictable in an I/O context.

Microtasks are not part of the Event Loop phases. They run between every phase transition and between individual callbacks within a phase. There are two microtask queues. The process.nextTick queue runs first and the Promise resolution queue runs second. Both are fully drained before the Event Loop advances to the next phase.

Calling process.nextTick queues a callback that runs before the Event Loop continues to the next phase, even before Promise callbacks. Use it sparingly and only when you need something to execute before any I/O in the current iteration. Overusing it can starve the Event Loop by blocking phase transitions if nextTick callbacks keep queuing more nextTick callbacks.

When Node.js performs I/O operations like reading files or making DNS lookups, it delegates these to libuv which manages a thread pool of four threads by default. These threads perform the blocking work on behalf of the main thread. When finished, they push the result callback into the appropriate Event Loop phase queue for the main thread to execute.