Content Delivery and Edge Networking Questions

Clarify requirements

• 50M monthly users, 2k RPS peak, p95 static asset SLO 90ms global — optimize edge hit-rate and PoP proximity; assume TLS, HTTP/2, and CDN with global backbone.

PoP placement

• Use 40–60 PoPs: dense in NA/EU/APAC (major metros + regional hubs), smaller PoPs in LATAM, MEA.
• Place PoPs in IX/major cloud regions to minimize RTT and peering hops.

Origin & origin-shield

• Two active regions (multi‑AZ) as origins behind an origin‑shield per region (regional cache tier) to aggregate cache misses.
• Shields reduce origin traffic by ~80–95%.

Cache-key design

• Base key: {host}:{path}:{query-significant}
• Strip tracking query params; include Accept‑Encoding and cookie/authorization only when necessary.
• Use Vary headers for compression / locale.

TTL & invalidation

• Default long TTLs (24h–7d) for static assets; short TTLs (5–60s) for frequently-updated files with cache revalidation (If-None-Match).
• Use instant purge API for critical updates and soft-purge + background revalidate for gradual refresh.

Minimize origin load / ensure freshness

• Use stale-while-revalidate and stale-if-error to serve stale while background refreshes.
• Conditional GETs to origin (Etag/If-None-Match) to return 304s.
• Pre-warm shields on deploys and push invalidation to shields before edge purge.
• Instrument metrics: edge-hit-rate, origin RPS, p95 latency per region; autoscale origin network and cache capacity.

Personalization

• Cache anonymous static assets; for per-user variants, cache key on deterministic tokens or use edge-side includes (ESI) to avoid origin hits.

Clarify requirements & constraints

• Cache dynamic pages at edge while preserving personalized fragments; minimize origin load; tolerate short personalization TTLs; defend against cache poisoning and stale private data exposure.

High-level architecture

• CDN with ESI support (or VCL/WASM on Fastly/Cloudflare Workers): edge nodes + origin + origin-shield.
• Origin-shield: single regional cache to reduce origin load and coordinate revalidation.
• Use fragment caching via ESI: public fragments cached long; personalized fragments rendered by edge using signed tokens or fetched from origin if needed.
• stale-while-revalidate: serve stale content immediately while revalidating in background (short SWR window).

Personalization (safe)

• Issue short-lived signed tokens/cookies (HMAC + timestamp + user-id hash). Validate signature at edge before revealing personalized fragment.
• Token contains only opaque id/claims; edge calls an auth/token verification service or validates HMAC with rotated keys.
• Edge maps token -> per-user fragment TTL (very short), otherwise render generic content.

Cache poisoning & stale personalization protection

• Separate cache keys: include only validated, canonical values (route, locale, content-version) — never include raw headers/cookies.
• Use Vary only on safe headers; include token validation result in cache key (e.g., anonymous vs authed), not raw token.
• Mark personalized fragments as private or use edge-side encrypted per-user caches when available.
• Short TTLs for personalized fragments + immediate invalidation on logout or profile change via purge APIs keyed by user-id.
• Strict input sanitization and header normalization at the edge; drop unknown headers to avoid injection into cache keys.

Operational/Network considerations

• Monitor cache hit ratios, origin request rates, and SWR revalidate latency.
• Key rotation for signing keys (KMS) with zero-downtime rollout.
• Rate-limit revalidation requests to protect origin; use origin-shield as backstop.

This design balances performance and safety: public fragments maximize cacheability; signed tokens and strict cache-keying prevent leaks and poisoning; origin-shield and SWR smooth spikes.

Situation & Goal
Explain how a CDN reduces perceived latency for static assets and sketch a simple architecture with edge PoPs, origin, cache-control/TTLs, and origin-fallback.

High-level architecture (ASCII)
Edge PoP (global) <--> Internet <--> Client (closest PoP)
|
v
Origin (S3/HTTP server) — Origin-shield (optional)

How CDN reduces perceived latency

• Geographic proximity: Edge PoPs serve content from locations near users, lowering RTT.
• TCP/TLS offload: TLS session resumption/shorter TCP handshake paths reduce connection setup time.
• Persistent connections: Edge keeps persistent upstream connections to origin, reducing new connection overhead.
• Caching: Popular static files (JS/CSS/images) served from edge avoids origin round-trips and saves bandwidth.

Cache-control, TTLs, origin-fallback

• Use Cache-Control headers: e.g., Cache-Control: public, max-age=86400, immutable for versioned assets; short max-age or must-revalidate for frequently changing resources.
• Origin-fallback: On cache miss, edge fetches from origin; implement origin-shield to consolidate requests and protect origin from thundering herd.
• Stale-while-revalidate / stale-if-error: let edge serve slightly stale content while refreshing, improving availability.

Trade-offs in TTL selection

• Long TTL: great for latency and origin load reduction, but harder to roll out updates; require cache-busting (file versioning).
• Short TTL: more freshness, higher origin load and latency on misses.
• Use long TTL + versioned filenames for static assets; short TTL for config/feature flags.

Cache warming & operational practices

• Cache-warming: pre-populate popular assets by pushing to PoPs or triggering synthetic requests from regional agents.
• Monitoring: track miss ratio, origin bandwidth, and TLS handshake metrics.
• Rate-limits & origin-shield to prevent origin overload during cache storms.

Bandwidth & connection benefits

• Saves origin bandwidth by offloading transfer to edge PoPs (especially for large images/videos).
• Reduces connection setup overhead for clients via resumed TLS and fewer full-round trips to origin.
• Improves resilience: edges can serve stale content when origin unreachable.

This design balances latency, freshness, and origin protection—use versioning + long TTLs for static assets and short TTLs or revalidation for dynamic content.