"200 Milliseconds" traces one HTTP request from click to render

"200 Milliseconds" (200ms.thenodebook.com) is an interactive, scroll-driven page built by Ishtmeet Singh for The Nodebook that walks through one illustrative HTTP POST request from start to finish: a fictional click on a coffee-shop laptop in San Francisco, all the way to a Node.js and Postgres backend in Ashburn, Virginia, and back to a rendered confirmation on screen. The scenario, the clicking user, the coffee shop, and the checkout are explicitly a constructed teaching example, not a report of a real transaction.

The page opens with DNS: the domain api.thenodebook.com carries a 300-second TTL on its A record, and in the illustrative run the resolver's cached answer is already 88 seconds old. It notes the DNS root zone is served by 13 named servers backed by more than 1,900 anycast instances worldwide, and that a blind DNS forger who cannot see the traffic has a 1-in-65,536 chance of guessing the query's random transaction ID. From there the walkthrough covers the TCP and TLS handshakes: the connection to Virginia runs at 62 milliseconds per round trip, and the pair of handshakes together cost 127 milliseconds; a second request that reuses that already-warm socket skips the handshakes and needs only one crossing of the continent instead of six, saving 116 milliseconds overall and finishing in about 95 milliseconds total. The page attaches a Let's Encrypt certificate for api.thenodebook.com valid for the illustrative window 2026-05-19 to 2026-08-17, a 90-day validity period it calls a deliberate design choice.

The request and its replies cross North America six times over roughly 4,700 kilometers of fiber each way, passing through about forty machines end to end. The Node.js server handling it, deployed 23 days earlier and running as process ID 1447, is serving this as its 1,203,001st request since it started; a layer-4 load balancer routes the connection so the TLS private key stays in exactly one place, meaning nothing between the laptop and the Node process can read the request in transit. On the kernel side, the box already holds 12,408 open connections in its established-connections table, the listening socket's SYN queue can hold up to 1,024 half-open connections, and Node's default accept backlog of 511 gets rounded by the kernel to the power-of-two 512.

Once the request reaches the application, the handler that actually processes it, checkout(), is eleven lines long, a sliver of the roughly hundred million lines of OS, browser, runtime and library code the page says are exercised to service the click. Node.js keeps a pool of ten pre-authenticated, open TCP connections to Postgres, so the query runs on a connection that is already live: Postgres reports a planning time of 0.048 milliseconds and returns the inserted row in 2.1 milliseconds total, assigning it the new order id 1,203,982. The page highlights that Postgres's Bind protocol step sends the query's parameter values separately from the parsed SQL, so a value containing SQL syntax, such as an attempted DROP TABLE, is stored as twenty-four characters of inert text in the sku column and never executed. The request body is 22 bytes; the response body, {"ok":true,"id":1203982}, is 24 bytes.

Adding it up, the page attributes 60% of the total 211.4 milliseconds to the TCP and TLS handshakes, 35% to the request and response physically traveling, and just 1.4% to everything the server did, kernel included. The full round trip covers a claimed 28,000 kilometers of travel. After the response lands, the finished frame still waits 4.4 milliseconds for the display's next 60 Hz refresh before it becomes visible. The person who clicked, in the page's telling, noticed none of it: the whole sequence, it says, felt instant, and took roughly a ninth as long as the two-second sip of coffee the same person takes while waiting. The closing section also cites 1996 research by Mogul and Ramakrishnan on "receive livelock," the failure mode where a machine taking one hardware interrupt per network packet collapses under load, as the historical reason modern kernels use NAPI-style batching instead, a design the page says makes a loaded machine more efficient rather than less.

The page is also a promotional vehicle: it advertises the author's paid course and book, "Nodebook Raw Mode," a 23-chapter deep dive into Node.js internals that this interactive walkthrough is built to sell.

Key facts

"200 Milliseconds," an interactive page by Ishtmeet Singh for The Nodebook, walks one illustrative HTTP POST request end to end, from a San Francisco coffee-shop click to a Node.js/Postgres backend in Ashburn, Virginia, and back, in 211.4 milliseconds total.
The request crosses the continent six times over about 4,700 km of fiber each way (28,000 km round trip) and touches roughly forty machines, yet the actual application handler that processes it is just eleven lines, a sliver of the roughly hundred million lines of OS, browser and runtime code the page says are exercised.
TCP and TLS handshakes account for 60% of the 211.4 ms total (127 ms); a second request that reuses a warm socket skips that setup and totals about 95 ms, a 116 ms saving overall; travel in flight takes 35%; everything the server did, kernel included, comes to 1.4%.
On the backend, Postgres returns the inserted row in 2.1 milliseconds using a pool of ten pre-authenticated connections; the page notes its Bind step sends query parameters separately from parsed SQL, so an injected value like a DROP TABLE is stored as inert text rather than executed.
The clicking user, coffee shop, and checkout are an explicitly illustrative scenario built to promote the author's paid course, "Nodebook Raw Mode" (23 chapters), not a report of a real transaction.

Why it matters

The page turns the felt instantaneity of a web click into an itemized account of where 211.4 milliseconds actually goes: 60% to TCP and TLS handshakes, 35% to the request and response traveling roughly 4,700 kilometers each way, and just 1.4% to everything the server itself does, Postgres query included. That breakdown runs against a common instinct to blame slow requests on backend code, when in this scenario the code is eleven lines and the time sits almost entirely in the connection and the network.

Who it affects

Web and backend developers, especially those working with Node.js and Postgres, and anyone trying to build intuition for how DNS resolution, TCP and TLS handshakes, and kernel-level connection queueing behave on a real round trip. It is also aimed at readers the author hopes to convert into buyers of his paid course.

How to use it

The page is free to read at 200ms.thenodebook.com with no signup required, built as a scroll-driven interactive walkthrough. It doubles as an advertisement for Ishtmeet Singh's paid course and book, "Nodebook Raw Mode," a 23-chapter series on Node.js internals.

How solid is it

The walkthrough is an explicitly invented scenario, not a report of a real transaction: the coffee shop, the clicking user, the SKU, and the checkout are illustrative by the author's own framing. Within that scenario the numbers are precise and internally consistent, for instance the 62 ms round trip figure lines up with the 127 ms cost attributed to the paired TCP and TLS handshakes, which reads as a carefully constructed teaching example rather than a claim about a specific real system.

Risks and caveats

Because the transaction is fictional, none of its figures describe a real production deployment. The page does not disclose which AWS region, load balancer, or Postgres version, if any, actually ran the demo versus which details are purely illustrative of a typical setup, and the IP addresses shown are documentation ranges rather than real production addresses. It also carries no real-world publication date, only the illustrative certificate window (2026-05-19 to 2026-08-17) and an in-scenario HTTP timestamp.

“Push it harder and it just batches harder. Overload makes the machine more efficient, not less.”

— "200 Milliseconds," on kernel packet batching under load