How Node.js Handles Concurrency on a Single Thread

How Node.js Handles Concurrency on a Single Thread

Node.js is single-threaded but handles thousands of concurrent connections. Here is how that works.

The Misconception

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

The Event Loop Model

Instead of a thread per request, Node.js uses the event loop. When an async operation starts, the thread moves on. When it completes, its callback is queued. The event loop processes these callbacks one at a time.

Non-Blocking I/O

The key is that I/O operations do not block the thread. Database queries, file reads, and network calls are delegated to libuv. The main thread is free to process other requests while waiting for I/O.

The Thread Pool for Blocking Work

Some operations cannot be done asynchronously, like certain file system operations. These go to libuv's thread pool (default 4 threads), 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, since 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

Node.js handles concurrency on a single thread through the event loop and non-blocking I/O. Async operations are delegated to libuv, and the thread processes callbacks one at a time. This scales for I/O-bound work but breaks down when the main thread is blocked by sync computation.