FSD Frontend System Design

Part I — The Pipes · Lesson 1.3

How the Web Works

In one lineURL → DNS → TCP → TLS → HTTP → parse → render: six hops, each with a cache in front of it.

Where you've seen itTyping youtube.com and pressing Enter — the most-asked opening question in a frontend interview.

  • Time16 min
  • DiagramSequence: Browser → DNS → CDN → Origin, with ms labels
  • Chapter1 · Networking

Diagram

diagram
Browser            DNS            CDN edge          Origin
   │                │                │                │
   │─ resolve ─────►│                │                │
   │◄─ 142.250.x.x ─│  (30ms, cached in OS/browser)   │
   │                │                │                │
   │─ TCP SYN ─────────────────────► │                │
   │◄─ SYN-ACK ──────────────────────│  1 RTT  (28ms) │
   │─ ACK + TLS ClientHello ────────►│                │
   │◄─ TLS ServerHello + cert ───────│  1 RTT  (28ms) │
   │─ Finished ─────────────────────►│                │
   │                                 │                │
   │─ GET / ────────────────────────►│                │
   │                                 │─ MISS ────────►│
   │                                 │◄─ HTML ────────│ (180ms)
   │◄─ 200 HTML (streaming) ─────────│                │
   │                                 │                │
   │─ GET app.css, app.js ──────────►│  HIT, no origin trip
   │◄─ 200 assets ───────────────────│                │
   │                                 │                │
   ▼ parse → style → layout → paint → composite
diagram
THE CACHE CHAIN — first hit wins, and the earliest is the cheapest

  ┌──────────────────┐
  │ Browser memory   │  0ms      ← same tab, this session
  ├──────────────────┤
  │ Browser disk     │  ~5ms     ← Cache-Control on a prior visit
  ├──────────────────┤
  │ Service Worker   │  ~5ms     ← your own code decides
  ├──────────────────┤
  │ CDN edge (POP)   │  ~30ms    ← shared across all users nearby
  ├──────────────────┤
  │ Origin server    │  ~200ms   ← last resort
  └──────────────────┘

How it works

  1. Parse the URL into scheme, host, path, query.
  2. Resolve the host — browser cache → OS cache → router → recursive resolver.
  3. Open a connection — TCP handshake (1 RTT), then TLS handshake (1 RTT on TLS 1.3).
  4. Send the HTTP request; the CDN answers from the edge or fetches from origin.
  5. Stream the HTML — the parser starts building the DOM before the last byte arrives.
  6. Discover subresources, fetch them on the same connection, then render.

Trade-offs

ChoiceBuys youCosts you
CDN in front of origin150ms+ per requestInvalidation strategy
TLS 1.3 + session resumption1 RTT, or 0 on repeatServer config work
preconnect to API origin1–2 RTT on first callWasted socket if unused
Long max-age + hashed filenamesNear-free repeat visitsBuild-time hashing required

Interview angle

"What happens when you type a URL and press Enter?"

  • Name the six stages in order and say which are cacheable — that alone passes.
  • Call out that the HTML streams: parsing overlaps with download.
  • Land on the frontend lever: the critical path is HTML → CSS → render-blocking JS.

Recap

  • Six stages: URL, DNS, TCP, TLS, HTTP, render.
  • Every stage has a cache; the earliest hit is the cheapest.
  • The frontend's job is shortening the critical path, not the total byte count.