Deep dive Edge & Caching 7 min Failure mode + fix

Why CDNs Make Far Servers Fast

Your server is 13,000 km away. Every hello pays for it.

Handshakes, encryption, copies and the fast lane, in plain language

Chapters

  1. Intro
  2. The speed-of-light tax
  3. The hidden hellos
  4. Enter the CDN
  5. Trick 1: Say hello nearby
  6. Trick 2: Keep copies close
  7. Trick 3: The fast lane
  8. Recap

Who it's for

Anyone curious why websites and AI apps load quickly even when their servers are on another continent, including non-technical viewers, product people and junior engineers. Every term is introduced after an everyday analogy.

Context

Shamira, in Mumbai, uses an AI chat app whose servers (the origin, with the GPUs and the model) are in a data centre in Virginia, roughly 13,000 km away. The app is a web page (HTML, scripts, fonts, images) plus live, personalised AI answers streamed from the origin.

Architecture

ComponentRoleNotes
BrowserShamira's side of every connectionDoes the TCP and TLS handshakes
Edge server (CDN PoP)The CDN's server in MumbaiTerminates TCP + TLS, caches static files
CDN backboneThe CDN's private network between its citiesMeasured routes, warm long-lived connections
OriginThe app's servers in VirginiaGenerates pages and AI answers

Request flow

  1. Without a CDN: TCP handshake (1 round trip) → TLS 1.3 handshake (1 round trip) → HTTP request and first byte (1 round trip). About 3 × 200 ms = 600 ms before the first byte (TLS 1.2: one more round trip).
  2. With a CDN: both handshakes finish at the Mumbai edge (about 10 ms per round trip). The edge answers static files from its cache, and forwards everything else to Virginia over a connection that is already open.

The failure modes

  • Distance itself. Each round trip to Virginia costs about 200 ms (illustrative), and a cold connection needs three of them before anything appears.
  • Plain-text second leg. With TLS terminated at the edge, some setups send edge-to-origin traffic unencrypted (e.g. a "flexible" TLS mode). The browser still shows a padlock, but anyone on the long path can read the traffic.
  • Cache busting. Random query strings on every URL, or cookies and Set-Cookie on static files, make every request look unique or private, so the edge can't reuse copies and nearly everything goes back to the origin.

Why it happens

Round trips are bounded by the speed of light in fibre (about 200 km per millisecond) and by indirect routes, and connection setup needs several of them. Misconfiguration silently removes the CDN's protections and savings.

The fix

  • SSL offload / TLS termination at the edge: handshakes happen close to the user; the edge keeps warm, reused connections to the origin.
  • Encrypt the second leg: full/strict TLS from edge to origin, validating the origin certificate (or a private tunnel).
  • Cache static assets: fingerprinted file names with Cache-Control: public, max-age=31536000, immutable; HTML with a short s-maxage plus stale-while-revalidate.
  • Keep URLs and cookies clean on static assets.
  • Use the backbone for uncacheable traffic (live AI answers), with streaming over the warm connection.

Trade-offs

  • Terminating TLS at the edge means trusting the CDN with decrypted traffic and certificates.
  • Long cache lifetimes need fingerprinted file names, or users keep stale files.
  • stale-while-revalidate can briefly show an old page.
  • Backbone routing and origin shields cost money and add another hop to debug.

Numbers worth knowing

  • Light in fibre travels about 200,000 km/s: about 65 ms one way for 13,000 km in a perfect straight cable (physics).
  • The 200 ms round trip, 10 ms edge round trip, 260 ms / 600 ms first-byte times and the cache hit percentages are illustrative.
  • TCP handshake costs 1 round trip; a full TLS 1.3 handshake 1 round trip; TLS 1.2 2 round trips (RFC 8446).

How the server says: keep a copy

response headers
# Files with a fingerprint in the name
GET /app.3f9a2c.js
Cache-Control: public, max-age=31536000, immutable

# The page itself changes often
GET /index.html
Cache-Control: public, s-maxage=60,
               stale-while-revalidate=300

How a CDN hides the distance

Say hello nearby

Handshakes finish at the edge

Lock both legs

Edge to server stays encrypted

Keep copies close

Static files come from the edge

Don't bust the cache

No random tags, no cookies on files

Take the fast lane

Warm, private routes for the rest

Measure it

Watch time to first byte and hit rate

Recap: before and after

Public internet

  • New hellos for every connection
  • Routes picked by price
  • Slows down at busy hours
vs

CDN fast lane

  • Warm connections, reused
  • Routes picked by live speed
  • Private links between cities

Same distance. Fewer trips, and faster ones.

Sources

  • RFC 9293 — Transmission Control Protocol (three-way handshake).

  • RFC 8446 — TLS 1.3 (1-RTT full handshake, 0-RTT resumption).

  • RFC 9111 — HTTP Caching (Cache-Control, s-maxage, immutable via RFC 8246).

  • RFC 5861 — stale-while-revalidate.

  • CDN provider documentation on TLS modes (flexible vs full/strict) and origin shields.

Coming next in the series: How Load Balancers Pick a Server

Found this useful?

Subscribe for the next episode, or share it with the person who owns this part of your stack.

Keep going