HTTP request lifecycle — animated end-to-end

Alice clicks "Place Order" on a merchant site. In less than a second, her browser talks to seven different systems across three continents. She types nothing, sees no errors, and doesn't know that DNS was resolved, TCP was handshaken, TLS was negotiated, a CDN was hit and missed, a load balancer picked one of three application servers, an auth token was verified, a Redis rate limit was checked, and a Postgres row was updated — all before the "Success" toast rendered.

Understanding this lifecycle in detail is what separates "I can write a web app" from "I can debug why my web app is slow." Every one of those seven steps is a place where latency accumulates, where authentication decisions happen, where errors originate, and where caching can save the day. The interview version of this question — "walk me through what happens when you type a URL and press Enter" — is deliberately open-ended because a Staff-level candidate can keep unpacking it for 45 minutes.

We'll trace a concrete scenario: Alice's browser calls POST https://checkout.acme.com/api/v1/orders. Behind that URL sits a real production stack — Cloudflare CDN, AWS ALB, three EC2 pods with private IPs, Redis for rate limiting, and Postgres for orders. We'll follow every packet, every header, every round trip. And then we'll toggle to see what changes if the same request went over plaintext HTTP instead of HTTPS.

The concrete scenario

  Alice (Bangalore)
   ↓  (residential DSL, 40ms to nearest CDN PoP)
  Cloudflare edge (Mumbai PoP)
   ↓  (backhaul 200ms to US-East)
  AWS ALB (us-east-1a)   ← L7 · terminates TLS · WAF · path routing
   ↓  (private VPC, 1ms)
  Backend pool:
    checkout-svc-pod-0   10.0.1.15  (us-east-1a)
    checkout-svc-pod-1   10.0.2.22  (us-east-1b)
    checkout-svc-pod-2   10.0.3.31  (us-east-1c)
   ↓  (auth check + rate limit)
  Redis cluster (session + rate limit)  10.0.4.10
   ↓  (business logic + write)
  Postgres primary (Multi-AZ)  10.0.5.10
   ↓  (2ms + fsync)
  ~ response bubbles back the same path ~

Step-by-step walkthrough

Click any step to zoom in. The timing shows what Alice's browser sees on a good network (median residential DSL from Bangalore to a US-East region). The right column shows what actually happens under the hood.

Same request, plaintext HTTP — what changes?

Suppose the merchant hadn't configured HTTPS. Or the DNS pointed at port 80 without redirecting. What does the same checkout call look like?

The killer insight: every header, body, and response is visible on the wire when using HTTP. Any router, any Wi-Fi node, any coffee-shop attacker with tcpdump sees Alice's Authorization: Bearer eyJ... token. Modern browsers refuse to send credentials over plaintext HTTP by default; if you type http://checkout.acme.com into Chrome, it redirects to HTTPS via HSTS preload before even resolving DNS. This is why HTTP-only public sites are near-extinct in 2025.

Where latency accumulates

Common optimizations, in order of impact

1. Cache the DNS lookup. Browser DNS cache saves 20-100ms per request after the first. Set your ttl on the DNS record deliberately — too short means clients rebeat your nameservers; too long means IP changes take hours to propagate.
2. Keep TCP connections alive. HTTP/1.1 keep-alive reuses the same TCP + TLS pipeline for multiple requests. HTTP/2 goes further with multiplexing. HTTP/3 uses QUIC over UDP to skip TCP handshake entirely after the first request.
3. TLS 1.3 with 0-RTT resumption. First connection is 1 RTT (down from TLS 1.2's 2 RTT). Resumed connections are 0 RTT — the client can send encrypted data in the very first packet.
4. CDN edge caching for static assets. HTML + JS + CSS + images cached at 300+ Cloudflare PoPs means Alice's browser fetches them 10-100ms away instead of crossing continents. Origin sees only cache misses.
5. Move rate limit checks to the edge. If your rate limit is per-API-key, run the check in a Cloudflare Worker before ever hitting your origin. Saves the entire backend round-trip for rejected requests.
6. Prefetch DNS + preconnect TLS. Browsers support <link rel="dns-prefetch"> and <link rel="preconnect"> hints. Use them for third-party origins your page will hit.

Real-world request tracing

Interview answer template

Key takeaways

1. An HTTPS request talks to at least 7 systems between the browser and the database — every one adds latency and can fail.
2. DNS + TCP + TLS handshake dominate cold-start latency. Optimizations focus on skipping repeated handshakes (keep-alive, HTTP/2, 0-RTT TLS 1.3, HTTP/3).
3. Plaintext HTTP means everything is visible on the wire. HSTS preload + browser policy make HTTP-only public sites near-extinct in 2025.
4. CDNs eliminate WAN latency for cacheable content. Netflix Open Connect and Cloudflare edge caches remove the round trip to origin for repeat requests.
5. Layered defense at every stage — HSTS at browser, TLS between edges, WAF at CDN, LB routing at ALB, rate limits at Redis, auth at backend. Attacker must break all of them.