CDNs

A CDN comes up whenever a design serves the same content to geographically spread-out users — and, like Redis, it's frequently named without the candidate saying what it's actually caching or how it stays fresh.

What it actually does

A CDN (Cloudflare, Akamai, Fastly, and similar providers all work this way) runs a network of edge points of presence (PoPs) physically distributed around the world. A request for a cached asset gets served from whichever PoP is geographically closest to the requester, instead of traveling all the way to the origin server — cutting both latency (a shorter physical distance to travel) and origin load (the origin never sees requests the edge can answer itself).

Cache invalidation

The standard joke — "there are only two hard problems in computer science: cache invalidation and naming things" — is genuinely relevant here. Two approaches: a short TTL, so stale content self-expires without any explicit action, or an active purge API call that evicts a specific URL from every edge PoP immediately. TTL is simpler and needs no coordination; purge is necessary when content changes in a way that genuinely can't wait out a TTL (e.g. a legal takedown, or invalidating a bad deploy). Most real setups use both — a moderate default TTL, with purge reserved for the cases that can't wait.

Static vs. dynamic content

A CDN is a strong, low-effort win for content that's the same for every user — images, videos, CSS/JS bundles, and any API response that doesn't vary per-caller. It does little to nothing for genuinely personalized, per-user dynamic content (an authenticated user's own feed, for instance) — caching that at the edge either doesn't help (each user's response is unique anyway) or actively risks serving one user's private data to another if the cache key isn't scoped correctly. Naming this boundary — what a CDN can and can't help with in this specific design — is usually a more useful signal than just saying "we'd put a CDN in front of it."

Cache keys

The cache key is usually the request URL, but real setups often vary it by additional headers (e.g. Accept-Encoding for compression, or a locale header for localized content) — the same URL can validly map to several cached variants. Getting the cache key wrong in either direction is a real failure mode: too narrow and you serve the wrong variant to some users; too broad and you fragment the cache into many near-duplicate entries that rarely hit.