Node.js In-Depth
Module A-3·23 min read

The math behind event loop lag, microtask queue starvation, and UV_THREADPOOL_SIZE tuning for cryptographic validation at scale.

Written by Jatin Jain Saraf · Architect of SupraScan

Module 2 — Event Loop Saturation & Thread Pool Offloading

What this module covers: The event loop from Module 0 was presented as a single loop. That was a simplification. The event loop has six distinct phases, each with its own queue, processed in strict order. When you have thousands of incoming transactions per second, microtask queues competing with I/O callbacks, timers firing at sub-millisecond intervals, and cryptographic operations queuing for a thread pool that defaults to 4 threads — the phase structure determines everything about your latency profile. This module covers the event loop precisely, shows you how to measure saturation, and gives you the tools to offload work correctly.

The Six Phases of the Event Loop

The Node.js event loop is not a simple loop over a single queue. It is a phased loop — in each iteration, it processes up to six distinct phases, and the order is non-negotiable.

   ┌───────────────────────────┐
┌─>│           timers          │ → setTimeout, setInterval callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │     pending callbacks     │ → I/O errors deferred to next iteration
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │       idle, prepare       │ → Internal use only
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │           poll            │ → Retrieve new I/O events, execute I/O callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
│  │           check           │ → setImmediate callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────▼─────────────┐
└──│      close callbacks      │ → socket.on('close'), etc.
   └───────────────────────────┘

Between every phase and between every callback within a phase, Node.js drains two special queues:

  1. process.nextTick queue — highest priority micro-queue
  2. Promise microtask queue — second priority

These micro-queues drain completely before the next phase or callback runs. This ordering has critical implications for high-throughput ingestion.

Phase 1: Timers

Executes callbacks scheduled by setTimeout and setInterval whose thresholds have elapsed. The "threshold" is a minimum — the callback won't run before the specified time, but it may run later if other phases are busy.

Production implication: If your ingestion pipeline uses setTimeout(fn, 100) as a flush trigger for a batch write, that timer will not fire at exactly 100ms if the poll phase is busy processing incoming transaction data. At 50K events/sec, the poll phase can be continuously occupied, delaying timers by hundreds of milliseconds.

Phase 2: Pending Callbacks

Executes I/O callbacks that were deferred to the next loop iteration by the OS (typically some TCP errors). Rarely populated in normal operation.

Phase 3: Idle, Prepare

Internal to libuv. Not accessible from JavaScript.

Phase 4: Poll

The most important phase for I/O-intensive applications.

The poll phase does two things:

  1. Calculates how long to block waiting for new I/O events (0ms if there are pending timers or setImmediate callbacks, otherwise up to some calculated maximum)
  2. Processes I/O callbacks in the poll queue

For a blockchain indexer receiving a continuous stream of transactions: incoming socket data triggers epoll notifications → libuv adds callbacks to the poll queue → the poll phase drains the poll queue. As long as data keeps arriving, the poll phase stays busy.

The blocking calculation is critical: if the poll queue keeps filling faster than it drains, the event loop never moves past the poll phase. Timers don't fire. setImmediate callbacks don't run. This is event loop starvation.

Phase 5: Check

Executes setImmediate callbacks. This phase runs after the poll phase, not before. If you want code to run "soon" but after current I/O has been processed, setImmediate is correct. If you want code to run "immediately" (before any I/O callbacks), process.nextTick is correct.

// Common pattern for blockchain indexers:
// After writing to DB, immediately schedule validation (before timers, after I/O)
db.write(tx).then(() => {
  setImmediate(() => validateAndIndex(tx));
});

Phase 6: Close Callbacks

Executes close event callbacks (socket.on('close', ...)). Cleanup only.

Microtask Queues: The Invisible Priority System

Before every phase transition and between every callback, Node.js drains microtask queues in priority order:

Priority 1: process.nextTick queue Priority 2: Promise resolution queue (queueMicrotask, .then, await)

Both queues drain completely before the event loop moves forward. This has a dangerous implication: if you continuously add items to these queues, the event loop never advances.

process.nextTick and Promise microtasks are like an airport's expedite lane that must be completely empty before the main line can move at all — if passengers keep cutting into it, the main line never advances no matter how short it looks from outside. A phase transition is the main line; the microtask queues are the expedite lane. Add faster than it drains, and everything behind it — I/O callbacks, timers, setImmediate — simply waits.

The Microtask Starvation Pattern

// DANGEROUS: infinite nextTick recursion
function processTransactions(queue) {
  if (queue.length === 0) return;
  const tx = queue.shift();
  handleTransaction(tx);
  process.nextTick(() => processTransactions(queue));  // ← recurses forever
}
 
// At 50K queued transactions:
// - processTransactions runs, schedules nextTick
// - nextTick queue drains: runs processTransactions again
// - Schedules another nextTick
// - nextTick queue drains again... 50,000 times
// - The event loop NEVER moves past the current phase
// - All I/O, timers, and setImmediate are starved
// CORRECT: yield to the event loop periodically
function processTransactions(queue) {
  const BATCH_SIZE = 100;
  let processed = 0;
 
  while (queue.length > 0 && processed < BATCH_SIZE) {
    const tx = queue.shift();
    handleTransaction(tx);
    processed++;
  }
 
  if (queue.length > 0) {
    // Use setImmediate to yield to the event loop after each batch
    // This allows I/O and timers to run between batches
    setImmediate(() => processTransactions(queue));
  }
}

Promise Chain Depth and Starvation

// This Promise chain processes 10,000 transactions without yielding
async function processAll(transactions) {
  for (const tx of transactions) {
    await parseTransaction(tx);      // adds to microtask queue
    await validateSignature(tx);     // adds to microtask queue
    await writeToDatabase(tx);       // adds to microtask queue
  }
}
// At 10,000 transactions with 3 awaits each: 30,000 microtasks
// Before the event loop advances past the current phase,
// all 30,000 resolve synchronously if they're CPU-bound
// → I/O callbacks starved for the duration of this batch

Event Loop Utilization (ELU): The Critical Production Metric

Event Loop Utilization (ELU) measures the ratio of time the event loop spends actively executing JavaScript vs idling in the poll phase waiting for I/O.

ELU = active_time / (active_time + idle_time)
 
ELU = 0.0 → event loop idle, no work to do
ELU = 0.5 → event loop 50% busy, 50% waiting for I/O
ELU = 0.9 → event loop 90% busy — danger zone
ELU = 1.0 → event loop fully saturated, no capacity for new work
// Measuring ELU in production
import { eventLoopUtilization } from 'node:perf_hooks';
 
// Capture baseline at startup
const startELU = eventLoopUtilization();
 
// Measure delta every 5 seconds
setInterval(() => {
  const currentELU = eventLoopUtilization(startELU);
  console.log(`ELU: ${(currentELU.utilization * 100).toFixed(1)}%`);
 
  if (currentELU.utilization > 0.85) {
    console.warn('EVENT LOOP SATURATED — offload CPU work or scale horizontally');
  }
}, 5000);
// Export to Prometheus for production alerting
import { register, Gauge } from 'prom-client';
 
const eluGauge = new Gauge({
  name: 'nodejs_event_loop_utilization',
  help: 'Event loop utilization (0–1)',
});
 
let lastELU = eventLoopUtilization();
setInterval(() => {
  const elu = eventLoopUtilization(lastELU);
  eluGauge.set(elu.utilization);
  lastELU = eventLoopUtilization();
}, 1000);

Alert thresholds for a UPI payment gateway:

ELUStatusAction
< 0.70HealthyNo action
0.70–0.85WatchProfile for CPU hotspots
0.85–0.95WarningOffload CPU work, scale
> 0.95CriticalImmediate intervention, add instances

Event Loop Lag: Measuring Actual Delay

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

Sign in & Register
PreviousModule A-2: Memory Leak Prevention PatternsNext Module A-4: Kernel-Level I/O Multiplexing: epoll, kqueue, IOCP

Discussion

0

Join the discussion

Loading comments...
PortfolioBlog

© 2026 Jatin Jain Saraf (JJS). All rights reserved.