CDN and Edge Delivery Explained — Cache-Control, PoPs, Edge Compute
Move static and cacheable content close to users to reduce latency and origin load.
A Content Delivery Network (CDN) is a globally distributed network of cache servers — called Points of Presence (PoPs) — strategically placed in major cities around the world. Instead of every user in Tokyo hitting your origin server in Virginia (adding 150ms of round-trip latency), they hit a Tokyo PoP and get a cached response in under 10ms.
CDNs work because most web traffic is repetitive: the same images, videos, JavaScript bundles, and API responses are requested by millions of users. Cache it once at the edge, serve it millions of times without touching the origin. This reduces both latency (closer server) and origin load (fewer requests to handle).
The key control mechanism is the Cache-Control header: it tells CDNs and browsers how long to cache a response, whether it can be shared across users (public vs private), and when to revalidate. ETags provide a fingerprint of the content — on revalidation, if the ETag matches the cached version, the CDN can return a 304 Not Modified instead of re-downloading. For dynamic content, modern edge platforms (Cloudflare Workers, Lambda@Edge) can run code at the PoP itself, reducing latency for personalized responses.
Key concepts
Step-by-step approach
- 1
Identify cacheable assets: static files (images, JS, CSS, fonts) are always cacheable; API responses may be cacheable depending on content freshness requirements.
- 2
Set Cache-Control headers on responses: max-age for browser caching, s-maxage for CDN caching, stale-while-revalidate for background refresh.
- 3
Configure cache keys: by default CDNs cache by URL. Add Vary headers if content differs by Accept-Language, Accept-Encoding, or cookie to prevent serving wrong content.
- 4
Plan cache invalidation: use content-addressed URLs (filename includes a hash) so new deploys automatically bust the cache without manual purging.
- 5
Use signed URLs for private content: protect paid content or user-specific files by signing URLs with an expiry time and secret — the CDN validates the signature before serving.
Key trade-offs
Cache hit rate vs. freshness
long cache TTLs improve hit rates and reduce origin load but serve stale content. Short TTLs keep content fresh but reduce CDN effectiveness. Design around how often content actually changes.
CDN at the edge vs. origin at the center
CDNs are great for static and cacheable dynamic content. For highly personalized, real-time, or transactional responses, the CDN layer must pass through to origin — adding a network hop.
Pull-through vs. push CDN
Pull CDNs fetch content from origin on the first cache miss (simpler to operate). Push CDNs require you to proactively upload content (more control, better for large files like video).
Common pitfalls
Caching responses with Set-Cookie headers: cookies are user-specific. Caching a response that sets cookies serves one user's cookies to all users. Use cache keys and Vary headers correctly.
No cache purge strategy: when a bug is deployed to static assets, you need to invalidate CDN caches immediately. Without a purge API call in your deploy pipeline, users see the broken version until TTL expires.
Caching error responses: a 500 error cached for 5 minutes means all users get errors for 5 minutes even after the fix is deployed. Set a very short or no-cache directive for error responses.
Interview questions on this topic
Practice answering these with AI feedback → Start on CrackLab
Continue learning — explore 207 more topics on CrackLab DesignHub
From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.
Related topics
Distribute traffic across healthy backends using L4/L7 algorithms and health checks.
DNS converts names to addresses and can steer users to healthy, nearby regions.
Choose service boundaries carefully. Microservices solve team and scale problems but add distributed complexity.