Module 05 · Lesson 04

The CDN is the biggest cache you own

Most bytes a service sends are static, identical for every user, and never change.

Intermediate 7 min read Updated 2026-11-01

What you will be able to do

  • Decide which content is edge-cacheable
  • Explain cache keys and why a wrong Vary header leaks data
  • Design signed URLs for private media
  • Describe byte-range delivery for video

What belongs at the edge

ContentCacheable?Why
JS/CSS with a content hash in the nameForever, immutableA new build produces a new filename
Images and fontsLong TTLRarely change; purge or rename on update
Public API JSON (catalog, trending)Seconds to minutesShared by all users, tolerates slight staleness
HTML entry pageShort TTL or revalidateMust reference the current asset hashes
User-specific API responsesNo, unless keyed correctlyOne user's response must never be served to another
Video segmentsLong TTLImmutable once encoded

The naming convention is the trick that makes long TTLs safe: app.9f3c1a.js can be cached for a year, while index.html is fetched for a minute with revalidation. You deploy the new asset first, then the HTML that points at it.

Cache keys, purges, and the leak

The edge stores a response under a key built from host, path, and selected headers. If the response depends on something not in the key, the edge will serve one variant to everyone — occasionally one user's private data.

  • Vary: Accept-Encoding for compressed variants; add Authorization or Cookie if the body depends on identity.
  • Purge by URL is fast; purge-by-tag (surrogate keys) lets you invalidate everything referencing a product after an edit.
  • A purge is not instant worldwide — assume tens of seconds and keep a versioned URL for anything critical.
  • Set Cache-Control: private on anything user-specific so intermediaries refuse to store it.
The classic CDN incident
An API is cached at the edge without identity in the key. A logged-in user's dashboard is cached and served to anonymous visitors. The fix is not a shorter TTL; it is making the response non-cacheable or keyed by user, which is usually a bad idea. Personalised data should not be shared-cacheable at all.

Private media: sign, do not proxy

If media is private, a common mistake is streaming it through your application so you can check permissions. That puts every byte on your servers. Instead, the application checks permission once and issues a signed URL with an expiry; the CDN validates the signature and serves bytes directly.

GET /media/report.pdf?expires=1767225600&sig=8f14e45f...

Edge checks: signature valid? not expired? path matches signature?
Yes -> serve from cache or origin, never involving your API again

Video is a different problem

Encode into multiple bitrates
A ladder of resolutions, each segmented into a few seconds of footage.
Segment for seeking
A player requests only the segments it needs, so a seek does not download the file from the start.
Adapt on the fly
The player measures throughput and switches up or down per segment — this is what keeps mobile playback smooth.
Serve segments from the edge
Segments are immutable and cacheable forever; only the manifest needs a short TTL when a live stream is in progress.
Origin requests saved by a warm CDN
90-99%
For static-heavy sites
Typical edge hit latency
10-40 ms
Depends on distance to the PoP
Video segment length
2-6 s
Shorter means faster adaptation, more requests
Global purge propagation
Seconds to a minute
Not instantaneous

In an interview, mentioning a CDN is only useful if you say what it serves and what its cache key includes. "Static assets and public media at the edge with a long TTL and hashed filenames, HTML with a 60 second TTL, and private files through signed URLs" is a complete answer in one sentence.

Worth remembering

  • Fingerprinted assets can be cached forever; HTML and API JSON need short TTLs or no caching.
  • The cache key is the contract — anything that changes the response must be part of it.
  • Private media should be a signed URL with an expiry, not a proxy that streams bytes through your service.
  • Video is segmented and delivered by byte range, so a seek does not download the whole file.

Checkpoint

Answer all 3 questions to finish the lesson.
1. Why can a file named `app.9f3c1a.js` be cached for a year?
Content-hashed names make the URL immutable. Deployment changes the HTML to reference a new URL instead of overwriting the cached one.
2. Private media should be delivered by:
Signing moves the byte serving to the CDN while keeping an authorisation decision in your application. Proxying makes your servers the bottleneck.
3. A personalised API response is cached at the edge and shown to other users. What was wrong?
Personalised responses must not be stored in a shared cache. The fix is `Cache-Control: private` or keying correctly, not merely shortening the TTL.
← PreviousInvalidation: TTL, versions, and the delete that arrives late