Type example.com and press Enter. In the ~200 milliseconds before the page appears, a dozen systems cooperate. Understanding each hop — and roughly what it costs — is the backbone of system design, because every design is just this lifecycle with more boxes bolted on.
We will trace one request end to end and attach a rough latency to each step. The numbers are order-of-magnitude, not exact.
Step 1 — DNS resolution (name → IP)
The browser needs an IP address. It checks caches in order — browser cache, then OS cache — then asks a DNS resolver (usually your ISP's). The resolver may walk the hierarchy (root → .com → the authoritative server for example.com) and return an address like 93.184.216.34.
- Cached: under 1 ms.
- Cold lookup: 20–120 ms across multiple round trips.
DNS answers carry a TTL, and caching them is why the second visit is faster. This is your very first cache.
Step 2 — TCP handshake (open a connection)
To talk to the server, the client opens a TCP connection with the three-way handshake: SYN → SYN-ACK → ACK. That is one full round trip before any data flows.
- Cost: ~1 RTT (round-trip time). Same city: ~5–20 ms. Cross-continent: ~100–150 ms.
RTT, not bandwidth, dominates here — which is exactly why putting servers closer to users (edge / CDN) matters.
Step 3 — TLS handshake (make it HTTPS)
For HTTPS, after TCP the client and server negotiate encryption and verify the certificate. TLS 1.2 costs about 2 RTT; TLS 1.3 cuts it to ~1 RTT, and session resumption can make repeat visits nearly free.
- Cost: 1–2 RTT on the first connection.
Steps 1–3 are pure setup — no application data yet — which is why connection reuse (keep-alive) is such a win: later requests skip all of it.
Step 4 — HTTP request / response
Now the browser sends the actual request:
GET / HTTP/1.1
Host: example.com
Accept: text/html
The server replies with a status line, headers, and a body:
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600
<html>...</html>
- Cost: ~1 RTT plus the server's processing time.
Step 5 — Load balancer
In production the request does not hit a single server. It arrives at a load balancer, which picks a healthy backend (round-robin, least-connections, and so on) and forwards it. The LB adds a small hop — sub-millisecond to a few ms inside a data center — and is often where TLS is terminated.
Step 6 — Application server
The app server runs your code: parse the request, check auth, apply business logic. Pure CPU work here is often 1–10 ms, but it usually needs data it does not already hold in memory.
Step 7 — Cache and database
The app first checks a cache (Redis / Memcached):
- Cache hit: ~0.1–1 ms, and the database is skipped entirely.
- Cache miss: fall through to the database. An indexed lookup on an SSD-backed DB is ~1–10 ms; an unindexed scan can be far worse.
The result then flows back: DB → app → LB → across the network → browser, which finally renders the page.
Where caching sits (top to bottom)
- Browser cache — reuse assets locally, zero network.
- DNS cache — skip name resolution.
- CDN / edge cache — serve static content near the user.
- Application cache (Redis) — skip repeated database reads.
- Database buffer pool — serve hot pages from RAM instead of disk.
Every layer exists to avoid the more expensive layer beneath it.
Putting the numbers together
A cold first visit crossing a continent can spend 100+ ms on DNS + TCP + TLS setup before a single byte of HTML moves. A warm repeat visit reuses DNS, the TCP connection, and cached assets, and feels instant. That gap — one-time setup cost vs steady state — is why keep-alive, CDNs, and caching appear in almost every design.
In the interview
- Trace a request through your diagram out loud; it exposes missing pieces.
- Separate RTT (latency) from bandwidth (throughput) — geography hits latency hardest.
- Point at where each cache lives and exactly what it saves.