Browser to Server: Anatomy of an HTTPS Request

Overview

What actually happens between pressing Enter and seeing pixels. The diagram walks one HTTPS GET through five tiers — name resolution, edge, application, data — and back. The pattern on display is layered request handling with cache-aside reads: every tier either answers from its own cache or forwards the request one hop deeper, and the response returns along exactly the same physical connections.

Components

Scenarios

Cold request for a personalised page — the expensive path, every cache misses:

1. [URL] → [DNS] → [DNS-OK] — resolver misses, asks the authoritative NS, caches the A record for its TTL. Skipped entirely on the next request.
2. [TCP] + [TLS] — two round trips to the PoP before a single byte of HTTP moves. This is why edge proximity dominates first-byte latency.
3. [MISS] at cdn-edge — the route carries a session cookie, so the edge refuses to serve or store it and forwards inward.
4. [FILTER] → [ROUTE] → [HANDLE] — WAF passes it, the LB picks a backend, the app server needs page data.
5. [MISS] → [QUERY] → [FILL] — cache-aside: Redis is cold, Postgres answers, the app writes the result back with SETEX … 60.
6. [RESPONSE] … [PAINT] — the response walks back up the same edges. Subgraph assets (CSS, JS) do hit the edge cache, which is why the second page view feels instant.

A warm request short-circuits at step 3 or step 5 and never reaches Postgres.

Tradeoffs / Failure modes

• DNS TTL is a commitment. A 300s TTL means a failover takes up to 300s to be seen by clients that already resolved.
• Cache-aside admits stale reads. Staleness is bounded by the TTL (60s here), not by writes. A write that must be visible immediately has to invalidate the key explicitly.
• The edge is the blast radius. If a PoP is unhealthy, anycast reroutes, but in-flight TLS sessions break and pay the two-RTT handshake again.
• Thundering herd. When a hot key expires, every concurrent request misses at once and stampedes Postgres. Needs a lock or probabilistic early refresh.
• Load-bearing assumption: reads vastly outnumber writes, and most bytes are static assets the edge can serve without ever touching the app tier.

References