1) Synchronous code is blocking

Synchronous operations run line by line, and each step waits for the previous one to finish.

If one operation takes a long time, everything after it must wait.

That blocking behavior is especially problematic in server runtimes.

2) Why blocking is a bigger issue in Node.js

Node.js handles JavaScript execution on a single main thread (event loop thread) per process. So many client requests can depend on that same thread’s responsiveness.

If one request runs a blocking operation on the main thread, other requests can get delayed.

A practical way to think about it:

• One thread orchestrates JS execution for all incoming work in that process
• If that thread is blocked, everyone waits

(Internally, Node.js can use worker threads in libuv for certain operations, but JS callback execution returns to the main event loop thread.)

3) Callbacks can be synchronous or asynchronous

A callback is just a function you pass to another function so it can be invoked from there. That does not mean every callback runs later or in the background.

Some APIs call your callback immediately and many times on the same thread, before the outer function returns.

Synchronous callback example: Array.prototype.sort

const nums = [3, 1, 4, 2];

nums.sort((a, b) => b - a);

console.log(nums); // [4, 3, 2, 1]

Here, (a, b) => b - a is a comparator callback. sort calls it repeatedly while comparing elements. Each call runs synchronously inside sort. When sort returns, sorting is already complete.

Other common synchronous callback examples:

• array.map((item) => ...)
• array.filter((item) => ...)
• array.forEach((item) => ...)

The key distinction

So callback and non-blocking are not the same thing. Many JavaScript APIs use callbacks without any async I/O at all. Node’s reputation for callbacks is mostly about the asynchronous style used for files, networks, and databases.

4) Non-blocking I/O with callbacks (fs.readFile)

To avoid blocking during slow work (like disk reads), Node.js uses asynchronous APIs like fs.readFile.

fs.readFile('<path>', 'utf-8', (err, data) => {
  console.log(data);
});

console.log('reading'); // this prints first

console.log('reading') prints first because readFile is non-blocking.

Node registers your callback and continues executing other code instead of waiting for file reading to finish.

5) What happens behind the scenes

At a high level:

1. Your app calls fs.readFile(...)
2. Node hands the file-read task to a background worker (via libuv thread pool / OS async facilities)
3. Main thread keeps running other tasks
4. When file read finishes, Node queues your callback
5. Event loop runs callback and passes (err, data)

So yes—your callback is stored and invoked later when the operation completes.

That is the core idea of non-blocking I/O.

6) Why callback hell happens

Callbacks are fine for one operation. Problems start when many dependent async steps are nested inside each other.

Callback hell example

fs.readFile('user.json', 'utf-8', (err, userData) => {
  if (err) return console.error(err);

  fs.readFile('orders.json', 'utf-8', (err, orderData) => {
    if (err) return console.error(err);

    fs.readFile('products.json', 'utf-8', (err, productData) => {
      if (err) return console.error(err);

      fs.writeFile('report.txt', 'generated report', (err) => {
        if (err) return console.error(err);

        console.log('Done!');
      });
    });
  });
});

Why this is difficult:

• Deep nesting reduces readability
• Error handling is repeated in many places
• Refactoring is harder
• Control flow becomes fragile

This pyramid shape is what people call callback hell.

7) Better alternatives: Promises and async/await

The callback hell example above works, but modern JavaScript provides cleaner ways to write asynchronous code.

Using Promises

const fs = require('fs').promises;

fs.readFile('user.json', 'utf8')
  .then((userData) => {
    console.log('User loaded');
    return fs.readFile('orders.json', 'utf8');
  })
  .then((orderData) => {
    console.log('Orders loaded');
    return fs.readFile('products.json', 'utf8');
  })
  .then((productData) => {
    console.log('Products loaded');
    console.log('All files loaded');
  })
  .catch((err) => {
    console.error(err);
  });

Promises help flatten nested callbacks into a more readable chain.

Using async/await

const fs = require('fs').promises;

async function loadData() {
  try {
    const userData = await fs.readFile('user.json', 'utf8');
    console.log('User loaded');

    const orderData = await fs.readFile('orders.json', 'utf8');
    console.log('Orders loaded');

    const productData = await fs.readFile('products.json', 'utf8');
    console.log('Products loaded');

    console.log('All files loaded');
  } catch (err) {
    console.error(err);
  }
}

loadData();

async/await is built on top of Promises and is generally the easiest style to read because it looks very similar to synchronous code while remaining non-blocking.

Evolution of asynchronous code in Node.js

Callbacks
    ↓
Promises
    ↓
async/await

Callbacks introduced non-blocking I/O, Promises improved readability and error handling, and async/await made asynchronous code feel much more natural to write and maintain.

Final thoughts

Node.js non-blocking design is one of its biggest strengths. Use asynchronous APIs (fs.readFile, network calls, DB calls) to keep the event loop responsive. Remember that callbacks appear in everyday sync APIs too (like sort and map). For multi-step async logic, prefer promises or async/await over deeply nested callbacks.