A user in Warsaw waits 3 seconds. Where did the time go?
“A user in Warsaw loads a page from your service hosted in Virginia and it takes 3 seconds; your server metrics show 30 ms of handler time. Walk through every layer where those 3 seconds could be, name the domain that explains each, and say how you would measure it.”
What this tests
- The complete map: browser, DNS, transport, TLS, RTT, loss, CDN, LB, scheduler, runtime, database, disk, response size, congestion
- Assigning each layer to the domain that explains it
- Turning a vague symptom into a measurement plan
- Not stopping at the first plausible cause
Answers by level
Read the beginner answer first and notice what is missing.
Start with the physics: Warsaw ↔ Virginia is ~100–120 ms RTT (Networking). A cold page load spends several round trips before the first byte: DNS (1 RTT to a resolver, more if the authoritative server is also in the US — Networking/DNS), TCP handshake (1 RTT — TCP), TLS 1.3 (1 RTT, or 2 for TLS 1.2 — TLS), then the request itself (1 RTT — HTTP). That is 4–5 RTTs ≈ 500 ms of pure waiting with zero bytes of payload, and every redirect repeats the last one.
Then the server side: the request passes a load balancer that may open its own connection to a backend (Architecture/Networking), waits in the accept queue, waits for a worker thread or an event-loop turn (OS scheduling), runs the handler (the 30 ms you measured), and inside it makes a database call that is its own socket round trip, query plan, buffer-pool lookup and possibly a disk read (Database/OS). Server metrics that measure handler time miss the accept queue and the worker wait, so 30 ms can be 300 ms of server latency (OS).
Then the response: a 3 MB page across 110 ms RTT with TCP slow start needs many round trips because cwnd starts at ~10 segments and doubles per RTT (TCP congestion control); 1% loss on the path halves it and adds retransmission timeouts (TCP loss recovery). Then the browser parses HTML, discovers CSS and JS, and fetches each — more round trips, more connections, possibly more DNS (Browser). A CDN edge in Frankfurt would cut the RTT to ~20 ms for everything it can serve, which is the reason CDNs exist (Edge networking).
Green flags · Red flags
- Multiplies RTT by round trips instead of saying "far away"
- Separates handler time from server latency (queues, scheduling)
- Includes the database call as a network + disk cost
- Mentions slow start or loss for the response transfer
- Proposes measurements per layer
- Stops at "add a CDN"
- Treats the 30 ms server metric as the server’s total time
- Ignores DNS and TLS round trips
- Cannot say what slow start does to a large response
- Blames "the network" as a single thing