<p><a href="url" target="_blank" rel="noopener nofollow">#</a> Node.js Async: The Illusion vs Reality</p>
<h2>Summary</h2>
<p>Node.js is well known for its non-blocking I/O model, but deep down this async facade hides a complex reality of synchronous operations, thread pool dependencies, and kernel-level limitations.</p>
<p>This article demonstrates Node.js’s async architecture and reveals where and why it falls short of being <strong>“TRULY” async</strong>.</p>
<hr>
<h2>Why This Matters</h2>
<p>Performance, latency, and scalability are directly impacted by whether operations actually run concurrently at the <strong>kernel level</strong> or are merely coordinated by the <strong>runtime (Node.js)</strong>.</p>
<p>When we assume everything is non-blocking while it isn’t, we encounter:</p>
<ul>
<li>Thread pool starvation</li>
<li>Increased response latency</li>
<li>Unexpected stalls in “async” code</li>
</ul>
<hr>
<h2>Node.js Architecture Overview</h2>
<p>In the classic Node.js model:</p>
<ul>
<li>JavaScript runs on a <strong>single main thread</strong></li>
<li>This thread executes the <strong>event loop</strong></li>
<li>All JS callbacks run here</li>
</ul>
<h3>libuv</h3>
<p><code>libuv</code> provides:</p>
<ul>
<li>The event loop abstraction</li>
<li>Cross-platform system behavior</li>
<li>A worker <strong>thread pool</strong> for blocking operations</li>
</ul>
<p>Default:</p>
<pre><code><span class="hljs-attr">UV_THREADPOOL_SIZE</span> = <span class="hljs-number">4</span>
</code></pre>
<h3>Network vs File I/O</h3>
<ul>
<li>
<p><strong>Network sockets</strong><br>
Use kernel-level async notifications:</p>
<ul>
<li><code>epoll</code> (Linux)</li>
<li><code>kqueue</code> (macOS/BSD)</li>
<li><code>IOCP</code> (Windows)</li>
</ul>
<p>These are <strong>true non-blocking I/O</strong>.</p>
</li>
<li>
<p><strong>File system &amp; some APIs</strong><br>
Many file operations are <strong>blocking at the kernel level</strong>.<br>
<code>libuv</code> offloads them to worker threads which:</p>
<ul>
<li>Run blocking syscalls</li>
<li>Send results back to the event loop</li>
</ul>
</li>
</ul>
<hr>
<h2>Where True Async Exists vs Where It Doesn’t</h2>
<h3>✅ True Non‑Blocking (Kernel Readiness)</h3>
<ul>
<li>Network sockets</li>
<li>Kernel notifies when data is ready</li>
<li>No thread is blocked or waiting</li>
</ul>
<h3>❌ Blocking (Thread Pool Based)</h3>
<ul>
<li><code>fs.readFile</code></li>
<li><code>fs.writeFile</code></li>
<li><code>open()</code></li>
<li><code>stat()</code></li>
<li><code>read()</code> / <code>write()</code></li>
</ul>
<p>These are executed in the <strong>libuv thread pool</strong>.</p>
<hr>
<h2>What Is Thread Pool Saturation?</h2>
<p>Thread pool saturation occurs when:</p>
<ul>
<li>All worker threads are busy</li>
<li>New tasks must wait in a queue</li>
</ul>
<h3>Effects</h3>
<ul>
<li>Tasks stop running concurrently</li>
<li>Execution happens in batches</li>
<li>Latency increases sharply</li>
<li>“Async” code behaves sequentially</li>
</ul>
<hr>
<h2>The Core Idea (Without Node.js)</h2>
<p>Imagine a restaurant:</p>
<ul>
<li>4 chefs → worker threads</li>
<li>20 orders → async tasks</li>
</ul>
<h3>What happens?</h3>
<ul>
<li>First 4 orders are cooked</li>
<li>Remaining 16 wait in line</li>
<li>Orders are processed in waves of 4</li>
</ul>
<p>Even if customers order <em>simultaneously</em>, food is cooked sequentially in batches.</p>
<p>That waiting line is <strong>thread pool saturation</strong>.</p>
<hr>
<h2>Thread Pool Saturation in Node.js</h2>
<ul>
<li>Node.js runs JavaScript on <strong>one thread</strong></li>
<li><code>libuv</code> maintains a worker thread pool</li>
<li>Some async APIs depend on this pool</li>
</ul>
<p>If the pool is full:</p>
<ul>
<li>New async tasks wait</li>
<li>Even unrelated work (like HTTP callbacks) can be delayed</li>
</ul>
<hr>
<h2>Concrete Code Examples</h2>
<h3>Example A — Thread Pool Saturation with <code>crypto.pbkdf2</code></h3>
<p><strong>Blocking behavior via thread pool</strong></p>
<p><img src="https://media.daily.dev/image/upload/s--ATHZvaqY--/f_auto/v1769795868/ugc/content_3289299c-a997-4a24-8c7a-4e2018a7e934?_a=BAMAMiiu0" alt="image"></p>
<h4>Output</h4>
<pre><code><span class="hljs-attribute">JS</span> FINISHED
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">0</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">1</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">2</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">3</span>
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">0</span>
</code></pre>
<p>➡️ The HTTP call is delayed because the thread pool is starved.</p>
<hr>
<h3>Increasing Thread Pool Size</h3>
<pre><code><span class="hljs-attr">UV_THREADPOOL_SIZE=</span><span class="hljs-number">5</span> <span class="hljs-keyword">node</span> <span class="hljs-title">src</span>/test.js
</code></pre>
<h4>Output</h4>
<pre><code><span class="hljs-attribute">JS</span> FINISHED
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">0</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">2</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">3</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">0</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">1</span>
</code></pre>
<p>➡️ With more threads available, the HTTP call is no longer blocked.</p>
<hr>
<h3>Example B — HTTP Calls First</h3>
<p>Thread pool is not saturated initially.</p>
<p><img src="https://media.daily.dev/image/upload/s--aZZ24N2n--/f_auto/v1769795935/ugc/content_1fea9104-8604-4b49-8ee0-d6a2d59b0a33?_a=BAMAMiiu0" alt="image"></p>
<pre><code><span class="hljs-attr">UV_THREADPOOL_SIZE=</span><span class="hljs-number">1</span> <span class="hljs-keyword">node</span> <span class="hljs-title">src</span>/test.js
</code></pre>
<h4>Output</h4>
<pre><code><span class="hljs-attribute">JS</span> FINISHED
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">1</span>
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">0</span>
<span class="hljs-attribute">HASH</span> DONE <span class="hljs-number">0</span>
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">3</span>
<span class="hljs-attribute">HTTP</span> DONE <span class="hljs-number">2</span>
</code></pre>
<p>➡️ Even with a single worker thread, scheduling order prevents starvation.</p>
<hr>
<h2>What Is <code>io_uring</code>?</h2>
<p><code>io_uring</code> is a Linux kernel interface (introduced in Linux <strong>5.1+</strong>) that enables <strong>true asynchronous I/O</strong> at the OS level.</p>
<h3>Key Characteristics</h3>
<ul>
<li>No blocking threads</li>
<li>No per-operation syscalls</li>
<li>High-performance async I/O</li>
</ul>
<p>Instead of:</p>
<blockquote>
<p>“Call a syscall and wait”</p>
</blockquote>
<p><code>io_uring</code> uses:</p>
<blockquote>
<p>Shared memory between user space and kernel space</p>
</blockquote>
<hr>
<h2>The Two Rings</h2>
<p><img src="https://media.daily.dev/image/upload/s--oJiBihhN--/f_auto/v1769795954/ugc/content_2813cfca-cb81-4b60-ad1c-d19a90f59c47?_a=BAMAMiiu0" alt="image"></p>
<h3>Submission Queue (SQ)</h3>
<ul>
<li>Application places I/O requests here</li>
<li>No syscall per request</li>
</ul>
<h3>Completion Queue (CQ)</h3>
<ul>
<li>Kernel posts completion events</li>
<li>App polls or waits for results</li>
</ul>
<p>➡️ <strong>No threads are blocked</strong></p>
<hr>
<h2>How <code>io_uring</code> Works (Step by Step)</h2>
<ol>
<li>Application creates an <code>io_uring</code> instance</li>
<li>App writes I/O requests into the SQ</li>
<li>Kernel processes them asynchronously</li>
<li>Kernel writes results into the CQ</li>
<li>App reads completions later</li>
</ol>
<p>All communication happens via <strong>shared memory</strong>.</p>
<hr>
<h2>Node.js + io_uring</h2>
<ul>
<li>Available <strong>only on Linux</strong></li>
<li>Requires kernel <strong>5.1+</strong></li>
<li>Can be enabled experimentally with:</li>
</ul>
<pre><code><span class="hljs-attr">UV_USE_IO_URING</span>=<span class="hljs-number">1</span>
</code></pre>
<p>This moves Node.js closer to <strong>true kernel-level async I/O</strong>.</p>
<hr>
<h2>Final Takeaway</h2>
<p>Node.js is <strong>asynchronous by design</strong>, but not everything is <strong>truly async</strong>.</p>
<p>Understanding:</p>
<ul>
<li>libuv internals</li>
<li>Thread pool limits</li>
<li>Kernel I/O behavior</li>
</ul>
<p>is critical for building <strong>high-performance</strong>, <strong>low-latency</strong>, and <strong>scalable</strong> systems.</p>
<p>Async is not magic, it’s architecture.</p>


Mohammed Ashiqur Rahman Baig

Node.js's async model isn't entirely non-blocking. While network operations use true kernel-level async I/O (epoll, kqueue, IOCP), file system operations rely on libuv's thread pool, which can become saturated. This causes "async" code to behave sequentially, increasing latency. The article explains thread pool saturation through code examples, demonstrates how UV_THREADPOOL_SIZE affects performance, and introduces io_uring as a Linux kernel interface that enables true asynchronous file I/O without blocking threads.

NodeJS - The Async Illusion