CDNs

A CDN is a cache you don't operate, sitting where the latency is

You already know caching: put a copy of an expensive result somewhere faster than recomputing it. A CDN applies that idea to the one cost you cannot optimise away in your own datacentre — the speed of light. A round trip from Singapore to us-east-1 is ~200-230 ms on fibre and no amount of Redis fixes it. A CDN is a network of PoPs (points of presence — racks of caching proxies in ~100-600 metros depending on the vendor) that terminate the user's TCP and TLS locally and serve the response from a cache 10 ms away.

Interviewers ask about CDNs because it is the fastest read on whether you think about where a system runs, not just what it does — and because the follow-up ("what happens when a logged-in user's page gets cached?") separates people who have configured a CDN from people who have heard of one.

How the request finds the nearest edge: anycast and DNS steering

There are two mechanisms and good candidates name both.

• Anycast. The CDN announces the same IP prefix via BGP from every PoP. Internet routers each pick the topologically shortest path to that prefix, so a packet addressed to 104.16.0.1 lands in Frankfurt from Berlin and in São Paulo from Rio, with no application logic involved. Failover is a BGP withdrawal: pull the announcement from a PoP and traffic re-converges elsewhere in seconds. The catch is that anycast is stateless routing — a mid-connection path change can land packets at a different PoP, which is why anycast TCP needs careful ECMP consistency (in practice all major CDNs solve this).
• DNS-based steering (unicast). The authoritative DNS server returns a different A record per resolver location, using EDNS Client Subnet to see the real user prefix rather than the resolver's. More control (you can weight by PoP load or cost), but it inherits DNS TTL latency: draining a PoP takes as long as the longest cached TTL, so these deployments run 20-60 s TTLs and pay the extra lookups.

Vendors differ: Cloudflare and Fastly lean on anycast, while AWS documents CloudFront as using DNS to route each viewer to the best edge location. Either way there is layer-4 load balancing inside the PoP. Say "anycast for the coarse routing, DNS or GeoIP steering when I need per-PoP control" and you have covered both families without claiming that any one vendor does everything.

The handshake arithmetic behind that claim: a brand-new TCP connection plus a TLS 1.3 handshake costs two round trips before the first request byte goes out, and the request itself is a third. To an origin 210 ms away that is about 630 ms before the first byte arrives; to an edge 8 ms away it is about 24 ms. HTTP/3 over QUIC folds the transport and TLS handshakes into one round trip, and resumed sessions can send data at once (0-RTT), which shrinks the gap for returning users but not the physics of an uncached miss.

Push vs pull: who decides what lives at the edge

The honest answer in an interview is "pull, with an origin shield." A shield is a designated mid-tier PoP that all other PoPs miss through, so a cold object costs one origin fetch globally instead of one per PoP. Vendors name it differently (Cloudflare's tiered cache, CloudFront's regional edge caches, which AWS puts between the PoPs and your origin). Edges also collapse concurrent misses for the same object into a single origin fetch (request collapsing). On a network with hundreds of PoPs that is the difference between a launch and an origin outage.

Cache-Control: the directives and what they actually do

Dry run: one URL's cache state through a stale-while-revalidate and stale-if-error cycle

/api/products/42 is served with Cache-Control: public, max-age=60, stale-while-revalidate=600, stale-if-error=86400, and the edge applies these directives with RFC 5861 semantics: both stale windows are counted from the moment the entry expires, not from the last fetch.

Three directives, three different jobs: max-age bounds normal staleness, stale-while-revalidate hides a slow refresh behind a stale response instead of making the user wait, and stale-if-error turns a dead origin into a non-event for up to a full day past expiry before it finally becomes the client's problem. (CloudFront also caps all of this at the distribution's maximum TTL, so a vendor setting can end the window sooner than the header.)

ETags and revalidation: paying for freshness in bytes, not seconds

When an object goes stale the edge does not have to re-download it. It sends a conditional request — If-None-Match: "9f2c1a" — and the origin replies 304 Not Modified with an empty body if the ETag still matches. You save the payload (often 99% of the bytes) but you still pay the full origin round trip, so a 304 costs the same latency as a 200. That is precisely the gap stale-while-revalidate closes.

• Strong ETag — byte-for-byte identity, required for range requests and resumable downloads. Usually a content hash.
• Weak ETag (W/"abc") — semantically equivalent. Right choice when gzip levels or a timestamp comment make bytes differ while meaning doesn't.
• Last-Modified / If-Modified-Since — 1-second granularity, and it lies whenever a deploy rewrites files without changing content. Prefer ETags; keep Last-Modified as a fallback.

Choosing a TTL: the question is "how stale is tolerable", not "how fresh can I be"

A useful reframing under pressure: TTL is a budget for how wrong you are willing to be, multiplied by how often the data changes. A 60-second TTL on data that changes hourly is nearly pointless conservatism; a 60-second TTL on data that changes every 200 ms is a deliberate, correct decision to serve approximate data fast.

Cache key design, and the bug that ends careers

The cache key is what the edge hashes to decide "have I seen this request before?" By default it is roughly scheme + host + path + full query string, plus whatever Vary adds. Two failure modes sit on either side of getting it right.

Going the other way, an over-precise key destroys your hit rate. Keys should be normalised before hashing:

• Sort and allow-list query params. ?sort=price&page=2 and ?page=2&sort=price must hash the same, and tracking params like utm_source, fbclid, gclid must be stripped — otherwise every ad click creates a unique, permanently-cold cache entry.
• Never key on the whole Cookie header. Key on a derived value instead: a boolean logged-in, or a plan tier. Two variants, not two million.
• Collapse device classes. Bucket User-Agent into mobile|desktop|bot at the edge and vary on that, never on the raw string.
• Lowercase the host, drop the default port, canonicalise trailing slashes — free hit-rate.

Invalidation: purge is the fallback, versioned URLs are the design

The strongest thing you can say here is that you avoid invalidation rather than optimise it. Content-addressed URLs (/static/app.9f2c1a.js, emitted by the bundler) make the problem disappear: new bytes get a new URL, the old URL stays valid forever, and rollback is just re-pointing the HTML. The HTML itself is the only short-TTL object in the system, and it is small.

Edge compute: the CDN stops being read-only

Every major CDN now runs your code in the PoP, but the runtimes are not interchangeable. CloudFront Functions are tiny JavaScript (ES 5.1) handlers with sub-millisecond duration, 2 MB of memory and no network access. Lambda@Edge is a full Node.js or Python function: up to 30 seconds, network access, 128 MB (viewer events) or up to 10 GB (origin events), and a container start that can add real latency. Cloudflare Workers run in V8 isolates with very fast starts; CPU time is capped at 10 ms on the free plan and defaults to 30 seconds (max 5 minutes) on the paid plan, with 128 MB per isolate. Fastly Compute runs WebAssembly. Pick by what the code must do, then read that vendor's current limits. Used well, edge code converts several origin round trips into edge-local work:

• Cache key rewriting. Normalise the query string, bucket the A/B variant, downgrade a cookie to a boolean — the normalisation rules above, implemented rather than configured.
• Auth at the edge. Verify a JWT signature locally and reject unauthenticated traffic 200+ ms (for a distant user) before it would have reached your origin. Revocation still needs an origin check, so keep tokens short-lived.
• Personalisation without breaking the cache. Cache one shared, anonymous HTML shell aggressively, then have the Worker stitch in the per-user fragment (name, cart count) from a KV lookup. You get a cacheable page and a personalised one.
• Geo / consent routing, redirects, signed URLs, bot scoring — all decisions that only need the request itself.

Be honest about the limits: edge runtimes have tight memory and CPU budgets, and eventually-consistent edge KV. They can open outbound TCP (Workers have connect(), and Cloudflare's Hyperdrive pools Postgres connections), but every query still pays the RTT from the PoP back to the database, and a chatty request that makes four of them at 200 ms each eats the entire win. Edge compute is for decisions about the request, not for business logic that needs your transactional store.

When a CDN is a 10x win, and when it changes nothing

The load-bearing metric in all six rows is the same: hit rate. Origin load scales with the miss rate: a 50% hit rate halves origin load (real, but not a 10x story); 90% removes 10x, 95% removes 20x and 99% removes 100x. Track both the request hit ratio and the byte hit ratio, because a few huge uncached video segments can dominate egress while the request ratio looks healthy, and use the standard Cache-Status response header (RFC 9211) to see which cache in the chain served a response. When an interviewer asks "how would you know it's working", the answer is hit rate by content type and origin egress per user — not "latency looks better."

Recognizing it in an unseen problem

• Signals: "global users", "millions of images", "video streaming", "our site is slow in India", or a read:write ratio quoted above about 20:1. Any of those and the CDN belongs in your first drawing, before you touch the database.
• The naive design puts one app tier in one region behind a load balancer and tries to fix the 200 ms of physics with more replicas. Replicas cut queue time; they cannot cut propagation delay.
• Distinguishing it from application caching: a CDN caches HTTP responses keyed by URL, near the user; Redis caches arbitrary values keyed by anything, near the service. If the thing you want to reuse isn't addressable by URL, or is per-user, it belongs in Redis — this is a layered-cache question, not an either/or.
• Estimate before you commit. 10 M daily users × 2 MB of assets ≈ 20 TB/day. If every byte left your origin at a list price near $0.09/GB, that's roughly $1,800/day. Browser caching removes some of those requests first; at 95% CDN offload only about 1 TB/day is fetched from your origin, and that origin-to-CDN leg is often discounted or free. Cost is a legitimate reason to reach for a CDN and it scores well, but credit the offload, not a cheaper per-GB rate.
• The pitfall to name unprompted: personalised content in a shared cache. Say the words "I'd default authenticated routes to private, no-store and make the CDN opt-in rather than opt-out" and you have pre-empted the follow-up question.
• Two named attacks to know. Web cache deception tricks a cache that decides by file extension into storing a victim's private page under a static-looking path (/account/orders/x.css); cache poisoning abuses request inputs that affect the response but are not in the key. Defences: honour the origin's Cache-Control, mark dynamic responses private/no-store, and do not cache by extension alone. Also worth a sentence: signed URLs or cookies for paid or private media, negative caching (a short TTL on 404s), range or segment caching for video, and multi-CDN for resilience.
• The second pitfall: full purges and cold-start stampedes. If the design has a global purge in it, pair it with a shield tier or staggered TTLs, or say out loud that the origin must be sized for the miss storm.