CDN and Edge Caching
Concept
A Content Delivery Network solves a different problem than application-layer caching: instead of shortening the path between an app and its database, it shortens the physical distance between a client and the server, by replicating content across geographically distributed edge points-of-presence (PoPs). A request from Sydney no longer has to round-trip to a single origin in Virginia — it's served from an edge node in Sydney instead, cutting latency that's dominated by physical distance and network hops, not compute time.
Two population models: a pull CDN fetches and caches content lazily on first request (cache-aside, applied geographically), while a push CDN has content proactively uploaded to edge nodes ahead of demand — pull fits general web traffic, push fits large media files with predictable, planned release timing.
Origin shield adds a regional cache layer between edge nodes and the origin: instead of every edge PoP's cache miss hitting the origin directly, misses route through one shield node per region first. The shield absorbs the "thundering herd" of correlated misses (e.g. a cache expiring simultaneously across dozens of edge nodes after a deploy) into a single origin fetch, then fans the result back out — often cutting origin request volume by one to two orders of magnitude for popular content.
Cache invalidation has three common shapes: TTL-based expiry (set a Cache-Control max-age and let it lapse — simple, but content can be stale for up to the full TTL window), soft/grace purges (mark content stale but keep serving the old version during a background re-fetch, trading a short staleness window for zero latency spike), and surrogate-key (tag-based) purging, where content is tagged at write time and a single purge call invalidates every cached object sharing that tag — the only approach that supports surgical invalidation without either guessing a TTL or purging everything.
Tradeoffs
| Dimension | Pull CDN | Push CDN |
|---|---|---|
| Population | Lazy, on first request per edge node | Proactive, uploaded ahead of demand |
| Best fit | General web assets, unpredictable access patterns | Large media, scheduled releases |
| Cold-edge penalty | Yes — first request per region always misses | None — content is pre-warmed |
| Invalidation method | Staleness window | Precision | Operational cost |
|---|---|---|---|
| TTL expiry | Up to full TTL | None (time-based, not content-based) | Zero — set once |
| Soft/grace purge | Near-zero (serves stale during re-fetch) | Coarse | Low |
| Surrogate-key purge | Near-zero, on demand | Surgical (invalidate exactly what changed) | Requires tagging discipline at write time |
The core tension mirrors application-layer caching's write-latency/consistency/durability triangle, but shifted to a geography axis: the wider and more aggressively content is cached at the edge, the cheaper and faster reads become — and the harder and more failure-prone it becomes to guarantee every edge node reflects a write that just happened.
When to use / when not to
- Fits static assets (images, JS/CSS bundles, video), and cacheable API responses keyed cleanly by URL and query parameters, especially for a geographically distributed user base where physical latency dominates.
- Origin shield earns its cost specifically for high-traffic content with many edge PoPs serving it — the correlated-miss protection it provides scales with fan-out; a low-traffic single-region deployment gets little benefit from an extra hop.
- Poor fit for highly personalized, per-user dynamic content (an authenticated dashboard rendered differently for every user) — there's nothing to actually share across edge nodes, so CDN caching adds an extra hop with no cache-hit benefit.
- Poor fit for genuinely real-time data (a live order book, a live sports score) where even a few seconds of edge staleness is a correctness problem — that traffic belongs on a direct or streaming path, not behind a TTL cache.
Common pitfall
Relying purely on TTL-based expiry for content that changes unpredictably. Set the TTL too high and users see stale content for the full window after every update; set it too low to compensate and the CDN barely caches anything, pushing traffic back onto the origin and defeating the reason a CDN was introduced. The fix is architectural, not a TTL tuning exercise — tag content with surrogate keys at write time so an update can purge exactly the affected objects on demand, decoupling cache freshness from a fixed timer.
Principal Engineer Lens
The Principal-level framing treats CDN adoption as a latency-budget and origin-protection decision, not a reflexive "put a CDN in front of everything." The strong review answer names which specific traffic is geographically distributed enough to benefit, what the actual staleness tolerance is for that content, and — for anything above trivial traffic — whether an origin shield is protecting the origin from correlated miss storms after deploys or TTL expirations. That's a materially different conversation from treating CDN as an undifferentiated performance checkbox.
Reel Script
Setup: Ask: if your app's database queries are all fast, why would a user on the other side of the world still see a slow page load?
Concept walkthrough: Explain that a CDN solves a geography problem, not a compute problem — it replicates content at edge PoPs physically close to users, cutting the network-hop latency that dominates cross-continent requests. Walk through pull vs push population, then origin shield as a regional buffer that absorbs correlated cache misses before they hit the origin directly.
Real example tie-in: Walk through a global e-commerce site's product images: cached at edge nodes worldwide via a pull CDN, with an origin shield in each major region absorbing the miss storm that happens right after a cache-wide TTL expiration, so the origin sees one fetch per region instead of one per edge node.
Tradeoffs & alternatives: Contrast the three invalidation strategies — TTL expiry (simple but stale-prone), soft purge (near-zero staleness, coarse), and surrogate-key purge (surgical, but requires tagging discipline at write time). Name the geography-axis version of the caching triangle: the more aggressively you cache at the edge, the harder freshness gets to guarantee.
Principal Engineer takeaway: The strong review answer isn't "we put a CDN in front of it" — it's naming the actual staleness tolerance for that specific content and which invalidation strategy matches it, the same way a caching-strategy choice has to match a read/write ratio.
Related
Sources: