How the Node.js Event Loop Handles Concurrency on a Single Thread

How the Node.js Event Loop Handles Concurrency on a Single Thread

Node.js handles thousands of concurrent connections on one thread. Here is how the event loop makes this work.

The Misconception

Many think single-threaded means one request at a time. It does not. Node.js handles many concurrent connections; the JavaScript code just runs on one thread.

The Event Loop Model

Instead of a thread per request, the event loop processes callbacks. When an async operation starts, the thread moves on. When it completes, its callback is queued, and the loop processes it. The thread is never blocked waiting for I/O.

Non-Blocking I/O Is Key

I/O operations (database, file, network) do not block the thread. They are delegated to libuv. The main thread is free to process other requests while waiting for I/O to complete.

The Thread Pool for Blocking Work

Some operations cannot be done asynchronously, like certain file system operations. These go to libuv's thread pool (4 threads by default), so they run off the main thread without blocking the event loop.

Why It Scales

This model uses far less memory than thread-per-request. One thread serves thousands of connections. The trade-off is that CPU-heavy work on the main thread blocks everything, which is why Node.js is best for I/O-bound work.

When It Breaks Down

When a callback does heavy synchronous computation, it blocks the event loop and all connections. This is the main scalability concern in Node.js, and why you must keep the main thread non-blocking.

The Takeaway

The event loop handles concurrency on one thread by processing callbacks from completed async operations. I/O is delegated to libuv so the thread stays free. This scales for I/O-bound work but breaks down when the main thread is blocked by sync computation.