Interactive · JS runtime + capacity planning

The JavaScript Event Loop, and how many instances you need

This page visually explains how the JavaScript / Node.js event loop handles asynchronous requests, and provides a simple calculator to estimate how many instances you might need for a given load.

← back to all guides

The full request path — from your machine to the CPU

Before a single line of your handler runs, the request crosses many layers. This is the real chain for GET /user/42 hitting a Node.js API behind a load balancer. Press Trace the path.

↓ event loop Your machine. The browser resolves the host, opens a TCP+TLS connection, sends the HTTP request. 🖥️ Your device browser / client opens TCP + TLS DNS resolves api.example.com to the load balancer's IP address (often cached). 🧭 DNS name → IP api.example.com Public Internet: routers and your ISP carry the packets to the datacenter edge. 🌐 Internet routers / ISP packets in flight Load balancer (ALB / nginx / Envoy): terminates TLS, picks one healthy backend, forwards the request. ⚖️ Load balancer picks a backend TLS term · health The server's OS: the NIC receives packets, the TCP/IP stack reassembles them, and the connection lands on the port your process is listening on (e.g. :3000). 🧩 OS kernel NIC · TCP/IP port :3000 · accept() Your Node.js process: libuv accept()s the socket. V8 holds your objects in the heap (memory); one main thread runs your JS (compute). ⬢ Node process V8 heap · libuv 1 main thread libuv's event loop dispatches the connection's 'request' event to your handler — the diagram below. 🔁 Event loop fires 'request' → your handler

Compute is the one main thread running your JavaScript; memory is the V8 heap holding your objects. Everything to the left of the Node process is the network and the OS — you rarely touch it, but it is the real path every request takes. Where the arrow points down, control enters the event loop shown below.

JavaScript Event Loop Visualizer

Trace a real request — GET /user/42 that runs a database query. Watch the call stack grow and unwind, the query get offloaded to libuv, the callback queue and promise microtasks fill and drain, and the event loop tick. Hover any box for its role.

Requests arriving from clients, waiting to be handled. Incoming Requests Clients arrive and wait to be handled. The single thread. One frame runs at a time; async calls return immediately. Call Stack idle The one JS thread. libuv thread pool / the OS run slow I/O off-thread so JS isn't blocked. I/O · libuv / OS Offloaded, off-thread. The Postgres/MySQL server actually executing the query. Database Runs the SQL, returns rows. Promise .then/.catch jobs. Drained fully after each task, before the next macrotask. Microtask Queue Promises — drained before next task. Each tick: drain microtasks, then take one callback from the queue and run it. Event Loop Polls queues, feeds the stack. tick Completed-I/O callbacks (macrotasks) wait here until the loop is free. Callback Queue · macrotasks Finished-I/O callbacks wait here. R
Press Play Demo to trace GET /user/42.
Speed:

Instance Sizing Calculator

A back-of-the-envelope estimate of how many instances a service needs to absorb its peak traffic, leaving headroom so no single instance runs at the edge of its capacity.

The busiest second you plan for — usually your traffic peak, not the average.
Display only — echoed in the result as a reminder of the latency you sized for.
How many QPS one instance can safely serve while staying inside the latency budget.
Capacity you deliberately leave unused to absorb spikes, deploys, and instance loss.
Changes the guidance below — the math stays the same.
Peak QPS–
Per-instance QPS (before headroom)–
Headroom–
Effective per-instance capacity–
Sized for p95 latency–
Required instances (rounded up) –
effective = perInstance × (1 − headroom%) raw = peakQPS ÷ effective instances = ceil(raw)

This is a simplified estimate. In practice, you would validate with load testing and monitoring (CPU, memory, latency, error rates).

Quiz · 47 questions

Test Yourself

Check your understanding of the event loop. Pick an answer to lock it in and see the explanation. Your score updates as you go.

0 correct · 0/47 answered

Home