CDN Caching and Edge Computing
A Content Delivery Network (CDN) is a globally distributed network of proxy servers, called edge nodes or points of presence (PoPs), positioned close to end users geographically. Instead of every request traveling all the way to a single origin server, the CDN serves cached copies of content from the nearest edge node, dramatically cutting round-trip latency and offloading traffic from the origin. CDNs were originally built for static assets — images, videos, JavaScript bundles — but have evolved into platforms that also cache dynamic API responses and execute custom logic directly at the edge.
Cricket analogy: Instead of every fan worldwide streaming from a single server in India, regional relay stations in London, Sydney, and New York rebroadcast the feed locally, cutting the delay for viewers far from the match venue.
How CDN caching works
When a client requests a resource, DNS routes it to the nearest edge node (often via anycast or geo-DNS). If that node already has a cached copy that hasn't expired, it serves it directly — a cache hit. On a miss, the edge node fetches the resource from the origin (or a regional mid-tier cache), stores a copy, and returns it to the client. Cache behavior is controlled largely through HTTP headers like Cache-Control, ETag, and Vary, which tell the CDN how long content is fresh and under what conditions a cached copy can be reused.
Cricket analogy: A local relay station that already has the last few overs recorded plays them back instantly (a cache hit); if it doesn't have the footage yet, it requests it from the central broadcast truck first, stores a copy, then relays it onward (a cache miss).
Static vs. dynamic content caching
Static assets with long-lived, versioned URLs (e.g. app.a1b2c3.js) are ideal CDN candidates: the content never changes for a given URL, so it can be cached indefinitely and invalidated simply by deploying a new URL. Dynamic content is trickier — an API response that's personalized per-user generally cannot be shared across users, but content that's the same for large audiences (a public leaderboard, a news homepage) can still be cached briefly at the edge with a short TTL, absorbing huge amounts of read traffic that would otherwise hit the origin.
Cricket analogy: A recorded highlights reel from a finished match never changes, so it can be cached forever and simply replaced by a new file for the next match; but a personalized 'your team's live score' widget can't be shared across fans the way a public leaderboard of tournament standings can be cached briefly for everyone.
Edge computing
Edge computing pushes beyond passive caching by running actual application logic on the edge nodes themselves — request routing, A/B test bucketing, authentication checks, image resizing, or even full serverless functions. Because this logic executes physically close to the user, it avoids a round trip to a distant origin for decisions that don't require the full application stack, further reducing latency for latency-sensitive interactions.
Cricket analogy: Rather than radioing every decision back to the central broadcast control room, the local commentary box handles instant replay selection and graphics overlays itself, avoiding the round-trip delay for calls that don't need the full production truck.
Request flow with CDN + edge compute:
1. Client (Tokyo) requests /api/feed
2. DNS/anycast routes to nearest edge PoP (Tokyo)
3. Edge function checks auth token, applies A/B bucket header
4. Edge checks cache for feed:region=apac -> HIT (age 8s, TTL 30s)
5. Edge returns cached, personalized-safe response directly
(no round trip to origin in US-East)
On cache MISS:
3'. Edge forwards to regional mid-tier cache (Singapore)
4'. Mid-tier forwards to origin (US-East) only if it also misses
5'. Response cached at mid-tier and edge on the way backNetflix's Open Connect places CDN appliances directly inside ISP networks, so popular video segments are served from a box physically near the subscriber, avoiding congested internet backbone links entirely during peak viewing hours.
Caching personalized or authenticated content at a shared edge cache without properly varying the cache key (e.g., ignoring the Vary: Cookie or Authorization header) can leak one user's private data to another — a serious and surprisingly common CDN misconfiguration.
- CDNs cache content at geographically distributed edge nodes to reduce latency and offload the origin.
- Cache behavior is controlled by HTTP headers like Cache-Control, ETag, and Vary.
- Versioned, immutable static assets are the easiest and safest content to cache aggressively.
- Shared, non-personalized dynamic content can still be cached briefly at the edge to absorb read traffic.
- Edge computing runs logic (auth, routing, transforms) at the PoP itself, avoiding origin round trips.
- Improper cache key handling for personalized content can leak private data between users.
Practice what you learned
1. What primarily determines how long a CDN treats a cached response as fresh?
2. Why are versioned, immutable static assets ideal candidates for aggressive CDN caching?
3. What distinguishes edge computing from traditional CDN caching?
4. What is the risk of caching personalized content at a shared CDN edge cache without proper Vary handling?
5. How does Netflix's Open Connect reduce video delivery latency?
Was this page helpful?
You May Also Like
DNS and CDNs
How the Domain Name System resolves human-readable names to IP addresses, and how Content Delivery Networks cache and serve content from edge locations close to users.
Why Caching Matters
Explains the core motivation for caching in system design — reducing latency and load by storing frequently accessed data closer to where it's needed.
Cache Invalidation Strategies
Explores how systems keep cached data consistent with the source of truth, covering TTLs, write-through/write-behind patterns, and explicit invalidation on updates.
Redundancy and Failover
Techniques for eliminating single points of failure by duplicating critical components and automatically routing traffic away from failed instances to healthy ones.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics