End-to-End Request Lifecycle

What happens when you hit enter

This is the integrative lesson: "what happens when you type a URL and hit enter" for a signed-in user loading a dynamic page. Everything from the previous five lessons appears as one hop in this chain. The skill is naming every hop, the RTT it adds, the cache that can short-circuit it, and how it can fail.

The path, hop by hop. Each stage below adds the next hop and says what it buys you:

One signed-in request, browser to database

Step 1 / 7

Stage 1 of 7: Before any network at all. A fresh cached response ends the chain here at 0 RTT, the cheapest possible outcome.

The response then travels back out: serialize (JSON or Protobuf), compress (gzip or brotli), set cache headers (Cache-Control, ETag) that decide what the browser and CDN may keep next time, CDN fills its cache on the way past, client renders.

Walk it:

1. Browser cache / service worker: before any network, the browser checks its own cache. A fresh cached response short-circuits the entire chain (0 RTT). This is the cheapest possible hit.
2. DNS: resolve the hostname. Cached at browser/OS/resolver, so usually 0 RTT; on a cold miss, a resolver walk adds one or more RTTs.
3. TCP: 3-way handshake, ~1 RTT. Reused/pooled connections skip this.
4. TLS: ~1 RTT for TLS 1.3 (0-RTT on resumption). So a cold HTTPS connection is roughly 2 RTTs before the first request byte.
5. Edge: CDN/anycast POP: anycast routes you to the nearest POP. For static or cacheable content, a CDN hit returns here without ever touching origin, the biggest short-circuit after the browser cache. A miss makes the POP fetch from origin (CDN fill) and cache it.
6. WAF: inspects for attacks (SQLi, XSS, bot patterns); can block before origin.
7. Load balancer -> reverse proxy / API gateway: L4 then L7; the gateway does routing, auth offload, rate limiting.
8. App server: now real work. Auth (validate the session/JWT). Then business logic.
9. App cache (Redis/Memcached): before hitting the database, check the cache. A hit returns in ~1ms and skips the DB. A miss falls through to the database (cache-aside), then populates the cache.
10. Database / downstream services: the authoritative read/write, plus any fan-out to other microservices (each its own network hop with its own timeout).
11. Response path: serialize (JSON/Protobuf), compress (gzip/brotli), set cache headers (Cache-Control, ETag) that decide what the browser and CDN may cache next time, the CDN fills its cache on the way out, and the client renders.

Hit versus miss is the whole game

On a warm path (browser cache fresh, or CDN hit, or Redis hit) most hops are skipped and you answer in single-digit ms. On a full cold miss (cold DNS, new connection, CDN miss, Redis miss) you pay every RTT plus the DB query, easily hundreds of ms.

Interview nuance: for a signed-in user on a dynamic page, the CDN usually cannot cache the personalized HTML, so the browser cache and the app-tier Redis cache do the heavy lifting, and the CDN mostly accelerates static assets and terminates TLS near the user. Say this; it is the distinction between caching a public marketing page and a logged-in dashboard.

Failure points and timeouts, per hop: DNS resolution timeout, TCP connect timeout, TLS handshake failure (expired cert), LB/gateway 502/503/504 when a backend is down or slow, app-to-DB query timeout, and downstream-service timeouts that need circuit breakers so one slow dependency does not cascade. Every hop needs a bounded timeout and a fallback, or a single slow dependency stalls the whole request.

Recap: a request walks browser cache -> DNS -> TCP -> TLS -> CDN/WAF/LB/gateway -> app -> auth -> app cache -> DB/downstream and back through serialize/compress/cache-header/render, where each layer adds an RTT and offers a cache that can short-circuit the rest, and every hop needs its own timeout so one slow dependency cannot stall the whole path.