Topic 9.5
CDN
In one line
Caching static (and some dynamic) content at edge nodes near users — the first latency lever at global scale.
Think of it like this
Your city having a local bookstore branch instead of everyone ordering from one warehouse across the country. You get the book (or article, or video) from nearby, much faster, because a copy was pre-placed close to you.
Key ideas
- 01
Content Delivery Network: edge servers cache copies at ISPs/regions; users hit the nearest edge, not the origin.
- 02
What it serves: static assets (JS/CSS/images/video), and API responses with provided TTLs (cacheable GETs).
- 03
How caching is declared: Cache-Control headers + ETag/Last-Modified — the ORIGIN decides what's cacheable.
- 04
Cache invalidation at scale: TTL, purge API, or versioned URLs //v2/app.js — the last one is the production favorite.
- 05
Dynamic acceleration: CDNs can also front APIs (WAF, TLS, compression) — value beyond static.
- 06
Interview math: video 90% of bandwidth → CDN saves origin bandwidth 100x.
Java / Spring map
- →
Spring: Cache-Control headers on static; @Cacheable is app-level, CDN is the edge layer — both.
Code & diagrams
The whole point of a CDN: most users never reach your actual server at all.
Explain without notes
A broken JS deploy: users still get the old file. Which CDN invalidation strategy fixes it instantly?
Practice
Specify cache headers + versioning scheme for images, fonts, and API responses.
Trade-offs
- ↔
Edge caching is a global cache — same stale-while-fast trade as Redis, geographically. TTL is your consistency dial.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I include CDN early in latency answers and know the purge/versioning story.