What is the difference between blocking and non-blocking I/O in Node.js?

Direct answer

Blocking I/O pauses the caller until the operation finishes — sync fs.readFileSync freezes the main thread; non-blocking I/O starts the operation and returns immediately, invoking a callback or Promise when libuv signals completion.

Node's design goal is non-blocking by default for server throughput — one thread serves many connections while waiting on DB or disk. Sync APIs exist for scripts and startup, not hot request paths.

	Blocking (sync)	Non-blocking (async)
Example	fs.readFileSync	fs.promises.readFile / readFile cb
Main thread	Stopped until I/O completes	Runs other callbacks while waiting
Use when	CLI tools, small config at boot	Servers, any concurrent workload
Risk under load	Entire API unresponsive	Starvation only if CPU work blocks thread

blocking-vs-async.js

import fs from "node:fs";

// BLOCKING — no other request handled during read
app.get("/bad", (req, res) => {
  const data = fs.readFileSync("large.json", "utf8");
  res.send(data);
});

// NON-BLOCKING — event loop serves other routes while disk reads
app.get("/good", (req, res) => {
  fs.readFile("large.json", "utf8", (err, data) => {
    if (err) return res.status(500).end();
    res.send(data);
  });
});

Async ≠ parallel — non-blocking I/O is concurrent scheduling, not multi-core JS execution.
Hidden blocking — JSON.parse on 50MB body, regex catastrophic backtracking — CPU blocks like sync I/O.
AceDevHub API — Fastify handlers use async/await + pg pool; never readFileSync per request on interview content routes.