System Design · core
CDN & Edge Delivery
Cache hierarchy, origin shield, and invalidation versus TTL at the edge.
Mental model
A CDN is a cache hierarchy whose top tier is geographic: the edge answers what it can, a shield tier absorbs the misses so the origin sees one request instead of one per POP, and only genuine misses reach you. The hard problem is the same as any cache — invalidation — and the practical answer is usually to avoid it: content-hashed URLs make every change a new key with an immutable, long TTL, so nothing ever needs purging. Reserve explicit purge for the cases where the URL genuinely cannot change.
How to study CDN & Edge Delivery
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use the linked roadmap and primary implementation references to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare CDN & Edge Delivery with Streaming Media, Load Balancing. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Decide the edge cache key and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Static asset delivery, video segments, and the first thing to check when origin load spikes without a traffic increase.
Common mistakes
- Relying on purge as the primary strategy, then discovering it is eventually consistent across POPs
- Caching a personalised response because the Vary and Cache-Control headers did not say otherwise
- No origin shield, so a cold cache means every POP stampedes the origin simultaneously
- Short TTLs everywhere as a substitute for thinking about cache keys
Learn from primary sources
Use the linked roadmap context and practice prompt.
Practice and explain it back
Decide the edge cache key
Implement edgePolicy({ url, hasAuthCookie, varyHeaders, contentHashed }) returning { cacheable, ttlSeconds, key }. Never cache when hasAuthCookie is true (ttl 0). A content-hashed URL is immutable: ttl 31536000. Otherwise ttl 300. The key is the url plus each varyHeader appended as '|<header>' in the given order.
Expected evidence: content-hashed -> one year; authed -> not cacheable; otherwise 5 minutes
Open the interactive drill →Review prompts
- Why do content-hashed URLs with a one-year TTL beat a short TTL plus purge-on-deploy?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.