What is the difference between blocking and non-blocking operations in Node.js?

Question

IT Interview Practice · Accepted Answer

**Blocking** operations run synchronously and hold the single JavaScript thread until they finish — nothing else can run in the meantime. **Non-blocking** operations start the work, return immediately, and deliver the result later via a callback, Promise, or event, so the thread stays free to do other things.

## Why Node is single-threaded yet non-blocking

Your JavaScript runs on **one** thread driven by the **event loop**. I/O (files, network, DNS) is delegated to **libuv**, which uses the OS async facilities and a small **thread pool** under the hood. While that work happens off-thread, the event loop keeps processing other callbacks. When the I/O completes, its callback is queued and run.

```js
const fs = require("node:fs");

// Blocking: the whole process waits here; no other request is served.
const data = fs.readFileSync("big.json");
console.log("done reading");

// Non-blocking: returns immediately; the callback runs when I/O finishes.
fs.readFile("big.json", (err, data) => {
  console.log("done reading");
});
console.log("this logs first");
```

## Blocking vs non-blocking

| | Blocking | Non-blocking |
|---|---|---|
| API style | `*Sync` (`readFileSync`) | callback / Promise / `async` |
| Thread | Holds the event loop | Frees the event loop |
| Throughput | One request at a time | Many concurrent requests |
| Use when | Startup/CLI scripts | Servers, request handlers |

## The trap: CPU-bound work still blocks

Non-blocking only helps with **I/O**. A heavy synchronous computation (JSON parsing a huge payload, crypto, image resizing, a tight loop) blocks the event loop even inside an `async` function, because the CPU work itself runs on the JS thread.

```js
// Blocks the event loop for the whole loop, despite being "async".
async function hash(n) {
  let x = 0;
  for (let i = 0; i < n; i++) x += Math.sqrt(i); // CPU-bound, synchronous
  return x;
}
```

Offload CPU-bound work to **`worker_threads`**, a child process, or a queue so the event loop stays responsive:

```js
const { Worker } = require("node:worker_threads");
new Worker("./cpu-task.js"); // runs on a separate thread
```

## Rules of thumb

- Never call `*Sync` APIs inside a request handler on a server.
- Use async I/O everywhere in the hot path.
- Move CPU-heavy work off the main thread.
- Watch for accidental blocking: large `JSON.parse`, synchronous crypto, regexes with catastrophic backtracking.

## Why it matters

Node's performance model depends entirely on keeping the single event-loop thread free. One stray blocking call — a `readFileSync`, a synchronous hash, a slow regex — stalls **every** concurrent request, not just the one that triggered it. Understanding what blocks and what doesn't is the difference between a server that scales to thousands of connections and one that freezes under load.

	Blocking	Non-blocking
API style	`*Sync` (`readFileSync`)	callback / Promise / `async`
Thread	Holds the event loop	Frees the event loop
Throughput	One request at a time	Many concurrent requests
Use when	Startup/CLI scripts	Servers, request handlers

Why Node is single-threaded yet non-blocking

Blocking vs non-blocking

The trap: CPU-bound work still blocks

Rules of thumb

Why it matters

Related questions