Blocking the Event Loop
Blocking the event loop runs slow synchronous or CPU-bound work on the single loop thread, freezing all other requests until it returns. Use non-blocking I/O, offload CPU work to worker threads, and chunk long tasks so the loop stays responsive.
Event-loop runtimes (Node.js, browser JavaScript, Python asyncio, Netty, Nginx) achieve high concurrency by running handlers on one thread that never blocks: each handler does a little work, registers callbacks for I/O, and yields. Blocking the event loop means doing something synchronous and slow on that thread — a tight CPU loop, a synchronous file read, a blocking database driver, a giant JSON parse — so the loop cannot service any other event until it returns.
Why It Happens
The synchronous API is right there and easier: readFileSync, a CPU-bound transform inline in a request handler, bcrypt with a high cost factor called synchronously, or a regular expression with catastrophic backtracking. In small tests with one user, the block is invisible. The cooperative model assumes every handler yields quickly, and one that doesn't silently breaks the contract for everyone.
Why It Hurts
There is only one thread. While it is busy, no other request progresses, timers do not fire, and health checks may fail — the server appears hung even though most requests are trivial. A single 500 ms CPU task adds up to 500 ms of latency to every concurrent request behind it. Under load this serializes the whole service and produces latency that scales with the slowest handler, defeating the entire point of the async model.
Warning Signs
- Synchronous file, crypto, compression, or DB calls inside request handlers.
- Large in-memory transforms, sorts, or
JSON.parseof big payloads on the loop. - Event-loop lag metrics spiking; p99 latency rising across unrelated endpoints together.
- Regexes on user input that can backtrack catastrophically.
Better Alternatives
- Always use non-blocking I/O APIs (the async variants) on the loop thread.
- Offload CPU-bound work to worker threads, a worker pool, a subprocess, or a separate service.
- Chunk long tasks and yield between chunks (
setImmediate,awaiton a tick) so the loop stays responsive. - Stream large payloads instead of buffering and parsing them whole.
- Bound and validate input to prevent pathological CPU (e.g., safe regex, size limits).
How to Refactor Out of It
Audit handlers for any synchronous call that can take real time: file system, crypto, compression, DB drivers, big parses, and risky regexes. Swap each for its async/non-blocking equivalent. Move genuinely CPU-bound work off the loop — into worker threads or a dedicated worker service — and communicate via messages. For unavoidable long computations, break them into chunks and yield to the loop between them. Add event-loop lag monitoring so regressions are caught early, and load-test to confirm that one heavy request no longer stalls the rest.