Dynamic Content Caching

The Challenge

 dynamic content resists caching because it varies:
 - per user (personalization, auth state)
 - per request (timestamps, randomness)
 - too fast to safely reuse (stock prices)

 but MOST dynamic responses vary LESS than developers assume —
 the art is separating what varies from what doesn't.

Micro-Caching

 very short TTLs on hot dynamic endpoints:

 GET /api/trending      Cache-Control: public, max-age=5

 1 second TTL at the edge with 50k rps:
 → origin sees ≤ 1 request/sec per key instead of 50k/sec
 users see ≤5s-stale trending lists; nobody notices.

 micro-caching turns "uncacheable" endpoints into
 origin-protecting ones. the single highest-leverage
 trick for read-heavy APIs.

Fragmentation Control

 cache keys must capture ONLY real variance:

 /api/products?page=2&color=red&utm_source=twitter&_=1690...
                          ↑ junk params fragment keys into misses

 config-level normalization:
   ignore: utm_*, fbclid, _
   sort remaining params canonically
   whitelist meaningful params only

 personalization variance handled by EXPLICIT keying:
   Vary: Accept-Language            (real variance)
   key on X-Currency header         (deliberate fragmentation)
   never key on cookies wholesale   (per-user = zero sharing)

Personalized Pages: The Composition Pattern

 page = mostly-shared shell + small personal fragments:

 ┌─────────────────────────────┐
 │ header/nav        SHARED    │ cached hours, all users
 │ product grid      SHARED    │ cached minutes  
 │ "Hi Sarah, cart"  PERSONAL  │ fetched separately!
 └─────────────────────────────┘

 techniques:
 - ESI (Edge-Side Includes): CDN assembles fragments server-side
 - client-side hydration: personal bits via separate API call
 - surrogate keys: shared parts purged surgically without
   touching other pages
 
 result: 95%+ effective hit rate on a "personalized" page.

Surrogate Keys (Tag-Based Purging)

 tag responses so events can purge GROUPS precisely:

 response: Surrogate-Key: products product-77 category-shoes
 event:     price changed on product 77
 action:    PURGE tag=product-77

 one event invalidates every page mentioning that product —
 without knowing URLs. this is how e-commerce keeps
 million-page catalogs fresh at the edge.

What Still Shouldn’t Cache

Data	Why
Auth-gated responses w/o careful keying	Leak risk across users
Truly per-request data (CSRF tokens)	Correctness
Rapid-decision data (inventory at checkout)	Business correctness

The checkout-inventory row is the classic judgment line: cache the BROWSING view (TTL 30s), never the DECISION path.

Interview Framing

“API is slow globally — use CDN?” scored arc: yes for GETs via micro-caching (quantify the 1-second-TTL math), key-normalization config, surrogate-key purges for freshness events, composition pattern for personalized pages. Naming what you would NOT cache (checkout decisions) completes the judgment picture.