Episode #31
Should You Block the Event Loop?
Every Node.js developer learns the same rule on day one: never block the event loop. Async is good, sync is bad, and the libuv thread pool is your friend. Then a real customer brought Luca and Matteo a compression problem that turned all of that upside down. Turns out, the rule is only half the story, and the other half can bring your app down. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into one of the most counterintuitive findings they've encountered while working with a customer: that for CPU-bound operations like gzip compression, async code running on a single core doesn't just underperform; it creates an unbounded queue that can take your application down with an out-of-memory explosion. And sync, the approach everyone told you to avoid, can give you a 50 to 120 percent throughput improvement. In this episode, we cover: ✅ Why the libuv thread pool becomes a bottleneck when Node.js is deployed on a single core, and why four async threads competing for one CPU is worse than doing it synchronously ✅ The hidden DoS risk in async compression: why the main thread keeps accepting requests while the libuv queue grows out of bounds and runs you out of memory ✅ Why event loop delay alone is not enough, and why Event Loop Utilization tells you what delay misses entirely when doing CPU-bound async work ✅ The PR Matteo opened to fastify-compress based on these findings, and the numbers that came out of it The takeaway? Async is not always better. For CPU-bound operations like compression and cryptography, the overhead of thread contention on a single core can cost you more than the event loop block you were trying to avoid. The right answer depends on whether you can control back pressure from your source, and most teams haven't asked that question yet.
