shreyansh

Content Delivery and Edge

30-Second Glance

  • A CDN is a globally replicated cache tier: PoPs serve bytes from ~10–50 ms away instead of ~200+ ms from origin, and absorb 10–100× traffic spikes before they touch you.
  • Pull (origin on miss) is the default; push (upload ahead) fits large, predictable, low-request-count objects.
  • Freshness is TTL + purge: long max-age with versioned URLs for immutables, short TTL or surrogate-key purge for HTML/API.
  • Geo-routing (anycast + latency/geo DNS) decides which PoP answers; edge compute (Workers, Lambda@Edge) decides what runs before origin is ever contacted.
  • The CDN is also your cheapest DDoS and TLS infrastructure: attack traffic dies at 300+ PoPs, not at your ALB.

PoPs and Request Flow

A Point of Presence is a cluster of cache + compute + TLS-termination servers placed in carrier-neutral facilities and ISP networks. Hierarchy: edge PoP (hundreds worldwide, serves users) → shield/mid-tier PoP (a few per continent, collapses concurrent misses so origin sees 1 fetch instead of 1,000 — origin shield) → origin. Cloudflare advertises ~300+ cities, Fastly ~100+ high-density PoPs, Akamai 4,000+ edge locations (many embedded inside ISPs); the count matters less than the two properties they buy: RTT collapse (user→edge ~10–50 ms vs user→origin ~150–300 ms intercontinental) and offload ratio (healthy static workloads see 90–99% of bytes served from edge).

Numbers to anchor with: cache HIT ~10–50 ms TTFB; cache MISS ~ HIT + origin fetch (often 200 ms–2 s for dynamic assembly); each 1% offload at 1 M rps spares 10k origin rps. TLS handshake cost (~1–2 RTTs, more without session resumption) is also paid at the edge once and amortized — another reason edge termination beats origin termination.

Push vs Pull

Pull (origin-pull, default) Push (upload to CDN storage)
Flow First request per PoP misses → CDN fetches from origin → caches per headers You upload objects to CDN storage (S3 + CloudFront, GCS + CDN) ahead of demand
Pros Zero publishing step; always eventually consistent with origin; infinite catalog Origin never hit for that object; survives origin outage; predictable for huge files
Cons Cold PoPs miss; origin must absorb the miss fan-in (mitigate with shield) Stale until re-pushed; storage cost for long tail; publishing pipeline to build
Use when Web pages, images, APIs — large catalogs, uneven geography Software releases, game patches, VOD libraries — few large objects, known upfront

Netflix Open Connect is the extreme push case (appliances pre-loaded inside ISPs); most interview answers should default to pull + shield and justify push only for the big-predictable-file case.

TTL, Invalidation, and Cache-Control

The header set is the actual API of a CDN — be able to write it:

  • Cache-Control: public, max-age=31536000, immutable for fingerprinted assets (app.a3f9c1.js) — cache a year, never revalidate; deploys change the filename, not the cache.
  • Cache-Control: public, max-age=60, stale-while-revalidate=30 for semi-dynamic pages — serve instantly, refresh in background (same semantic as the app-tier SWR in Cache Patterns and Eviction).
  • s-maxage to give the CDN a different (usually longer) TTL than browsers; Vary: Accept-Encoding (handled automatically now) and careful Vary otherwise — every Vary dimension multiplies cache entries.
  • ETag/Last-Modified + If-None-Match for cheap revalidation (304, no body).

Invalidation options, fastest to slowest: versioned URLs (instant, free — prefer always for statics), surrogate-key/tag purge (one API call invalidates all objects tagged product:123 — the correct answer for catalog-scale invalidation, ~100 ms–few s globally), exact-URL purge, full purge (operationally a self-inflicted cold start — mass expiry = thundering herd at origin). TTL for HTML shells is typically 0–60 s with SWR; APIs behind CDN get short TTL + Vary: Authorization discipline (never cache keyed sessions under shared keys).

loading diagram…

Geo-Routing

Getting the user to the right PoP: BGP anycast (same IP announced everywhere; internet routing delivers to the nearest — Cloudflare/Fastly model, failover in seconds, but "nearest" is BGP-nearest not latency-nearest), latency-based DNS (Route53 measures and answers per-user — precise, but DNS caching delays shifts by the TTL), and geoproximity/geolocation DNS (regulatory pinning: EU users → EU PoPs). Real stacks layer them: anycast for the edge, latency-based DNS for origin-region selection and multi-region failover (ties into the GSLB tier in Scaling Out and Load Balancing). Mention EDNS Client Subnet: without it, DNS-based routing sees the resolver's location, not the user's — a classic source of misrouted traffic.

Edge Compute

Running code at the PoP, before origin: Cloudflare Workers / Fastly Compute (V8/Wasm isolates, ~0–5 ms cold starts, KV at edge with ~10–60 s global replication lag), Lambda@Edge / CloudFront Functions (viewer-request/response hooks, heavier but inside AWS IAM). Legitimate edge workloads: A/B bucketing and redirects, JWT verification, personalization assembly from cached fragments (ESI-style), bot scoring, image resizing per device. Budgets: sub-millisecond–few-ms CPU limits per request, no long-lived connections — anything needing cross-request coordination or >50 ms compute stays at origin or in a regional service. Edge KV/edge dictionaries back rate limiting and feature flags with local reads.

Trade-offs

Approach Pros Cons Use when
CDN pull + shield Simple; origin-consistent; huge offload Cold-PoP misses; shield is another hop on miss Default for web/API static and semi-static
Push to edge storage Origin-independent; best for giant files Publishing pipeline; stale-until-repush Releases, patches, VOD
Long TTL + versioned URLs Near-100% hit ratio; zero purge ops Requires build-time fingerprinting discipline Immutable statics — always
Short TTL + SWR Fresh-ish dynamic content at edge speed Bounded staleness; background revalidation load HTML shells, semi-dynamic APIs
Surrogate-key purge Instant targeted invalidation at catalog scale Tagging discipline; provider API limits Catalogs/pricing where staleness costs money
Edge compute Personalization without origin RTT; pre-origin policy CPU/time caps; edge-state eventual consistency Auth checks, bucketing, redirects, bot defense

Interview One-Liners

  • Q: 1 M rps of product images, origin handles 20k rps. CDN config?
    A: Pull + origin shield, immutable fingerprinted URLs with 1-year TTL → ≥98% offload leaves ~20k or fewer origin rps; shield collapses the miss fan-in.
  • Q: Price change must be visible in < 5 s globally. How?
    A: Short TTL won't do it — tag objects with surrogate keys (product:123) and purge by tag on price events; versioned URLs for everything else.
  • Q: Push or pull for a 40 GB game patch on launch day?
    A: Push to edge storage days ahead; pull would stampede origin with synchronized cold misses from every PoP.
  • Q: EU user data must not be served from US PoPs. Mechanism?
    A: Geolocation DNS + regional PoP pinning (not anycast alone — BGP-nearest ignores borders); cache partitions per region.
  • Q: Where do you verify JWTs — edge or origin?
    A: Edge (Workers/Lambda@Edge with cached JWKS): rejects unauthenticated traffic before it costs origin capacity; origin still re-verifies for defense in depth.
  • Q: Full CDN purge after a bad deploy — safe?
    A: No — it's a synchronized cold start. Prefer versioned-asset rollback (instant) plus targeted tag purges.