Non-Blocking I/O Model
Non-blocking I/O means Node initiates an I/O operation and immediately returns control to the caller rather than waiting for it to complete. A callback or promise resolves when the operation finishes.
Non-blocking I/O = a chef who never stands idle waiting for water to boil. He starts boiling, chops veggies, preps sauce. But if someone hands him a 50-pound block of cheese to grate (JSON.parse), he blocks the whole kitchen until he's done grating.
Node's non-blocking model allows a single thread to handle thousands of concurrent connections. When a request comes in, Node registers event handlers for read/write, processes other requests while waiting, and resumes when data is available. This eliminates the per-connection thread overhead that synchronous servers (Apache prefork) incur, reducing context-switching and memory usage dramatically.
The cost is callback orchestration complexity and the risk of blocking the event loop. Any synchronous operation that takes >10ms effectively increases latency for all concurrent requests by that amount. Common inadvertent blockers: JSON.parse of a 50MB payload, synchronous regex with catastrophic backtracking, fs.readFileSync in a hot path, or a tight for-loop over millions of records. The --clinic tool (node-clinic) and the 'blocked-at' npm module can detect event loop lag in production. Express middleware chain synchronously executes until it encounters an async boundary, so synchronous middleware with complex logic compounds the problem.
Non-blocking I/O means Node doesn't wait for I/O to finish—it registers a callback and processes other events. This lets one thread serve thousands of simultaneous requests. The critical corollary: any synchronous CPU work on the main thread blocks all concurrent requests. Tools like node-clinic and the --inspect profiler identify event loop blockage.
JSON.parse is synchronous. Parsing a large request body (e.g., a 10MB JSON payload) on the main thread blocks the event loop for potentially hundreds of milliseconds, stalling all other requests—even if the underlying HTTP reading was async.