TTL and Invalidation at the Edge

Two Audiences, Two Headers

 the same response passes two caches with different needs:

 [browser] ◄─── Cache-Control: max-age=60        fresh 1min locally
    ▲
 [edge]    ◄─── Surrogate-Control: max-age=86400  fresh 1day at CDN

 CDN honors Surrogate-Control when present, else Cache-Control.
 without this split: long browser TTL = users stuck on stale
 content you can't evict (browsers can't be purged!).

 rule: LONG freshness at edges (controllable),
       SHORT or none in browsers (uncontrollable).

The Purge Toolkit

 when TTL is too slow, CDNs expose invalidation APIs:

 PURGE BY URL:
   POST /purge {"urls": ["/products/77"]}
   precise; needs URL knowledge

 PURGE BY TAG (surrogate keys):
   response carries:  Surrogate-Key: product-77 shoes sale
   event triggers:    PURGE tag=product-77
   → every page containing that product refreshes
   THE tool for entity-driven sites (catalogs, news)

 PURGE EVERYTHING:
   nuclear option → global stampede on origin. avoid;
   use prefix/tag purges instead.

Soft Purges and Stale Fallbacks

 HARD purge: next request = miss → origin fetch (stampede risk)
 SOFT purge: mark stale; serve STALE while one fetch revalidates
            (stale-while-revalidate semantics applied to purges)

 production default: soft purge + SWR =
   freshness events cause zero user-visible latency
   and zero origin spikes. configure it once, benefit forever.

Deploy Strategies That Avoid Purging

Pattern	Mechanism	Fit
Content-hashed assets	New filenames = new keys	JS/CSS/media
Versioned API paths	/v2/… alongside /v1/…	Breaking API changes
Timestamped pages	/blog/2026/post-slug	Publish-only content
Tag-based soft purge	Event-driven surgical refresh	Entity updates

 purges are for CORRECTIONS (bad price, removed content);
 versioning is for PLANNED changes.
 architectures that never need emergency purges
 are architectures that sleep well.

TTL Ladders by Content Class

 hashed static assets      1yr immutable     (never invalidated)
 fonts/images              months
 marketing pages           hours + tags
 product/catalog pages     minutes + tags
 trending/API GETs         1–30s micro-cache
 personalized fragments    no-store (separate call)

 attach SURROGATE KEYS to everything entity-derived at publish time,
 not retroactively during incidents.

Interview Framing

“Price changed — how fast do all pages reflect it?” scored answer: surrogate-key tagging at publish, soft-purge-by-tag within seconds, SWR absorbing the refetch wave, plus the architectural note that hashed assets make MOST content purge-free. The two-header split (Surrogate-Control vs Cache-Control) is the detail that marks hands-on CDN experience.