CDNs in depth

The problem: Snip goes global

Half of Snip's clicks now come from Asia and Australia. Every redirect from Sydney still crosses the Pacific to Virginia and back, and a big customer complains that their campaign links feel slow. In 02.05 A CDN for static content, Snip kept redirects at the origin because clicks answered at the edge are never counted. Now the trade-off has changed, so Snip will cache redirects at the edge and solve counting another way.

A redirect is a much harder thing to cache than a fingerprinted script. It can change (owners edit links), it must disappear quickly if it's blocked, and every click matters. Doing it well takes five ideas.

1. The cache key decides your hit rate

An edge stores each response under a cache key. By default that's roughly the full URL: scheme, host, path and query string (Cloudflare's default also includes a few headers, such as Origin). So these are three separate cache entries, even though Snip answers them identically:

https://snip.link/x7Kp
https://snip.link/x7Kp?utm_source=newsletter
https://snip.link/x7Kp?fbclid=IwAR3...

Social networks and email tools add tracking parameters, often unique per click. Left in the key, they spread one link over thousands of entries, and the hit rate collapses. Snip's redirect doesn't depend on the query string, so it configures the CDN to leave the query out of the key.

The Vary response header works the other way: it adds request headers to the key. Vary: Accept-Encoding is normal. Vary: User-Agent or Vary: Cookie splits every entry by browser or by user, and quietly turns a cache into a pass-through.

2. Separate lifetimes for the edge and the browser

Snip can purge a CDN, but it can't reach into a browser (06.01 Where caches live). So it gives them different lifetimes:

HTTP/1.1 302 Found
Location: https://shop.example/summer-sale
Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30, stale-if-error=86400
Surrogate-Key: link-x7Kp owner-4821

• max-age=0: to a browser the copy is stale at once, so it checks again (at most reusing the old copy during the stale-while-revalidate window below). An edit is never stuck in someone's browser.
• s-maxage=60: shared caches (the CDN) may keep it for 60 seconds. Shared caches use s-maxage in place of max-age when both are present.
• stale-while-revalidate=30: for 30 seconds after that, the edge may serve the old copy while it refreshes in the background, the soft-TTL idea from 06.05 Stampedes and request coalescing.
• stale-if-error=86400: if the origin returns a 500, 502, 503 or 504, the edge may serve the stale redirect for up to a day.

That last line means popular Snip links keep working even if Snip's origin is down.

3. Tiers and collapsing protect the origin

A CDN with 300 locations has 300 separate caches. A popular link can miss 300 times per minute (once per edge per TTL), and a brand-new link that goes viral misses in every city at once.

• Tiered caching: edges are split into lower tiers and upper tiers. A lower-tier edge that misses asks an upper tier, and only the upper tier asks the origin. 300 misses become a handful.
• Request collapsing: when many requests for the same uncached object reach one edge at once, it sends one request to the origin and queues the rest behind it, the CDN version of coalescing (06.05 Stampedes and request coalescing). The HTTP caching standard, RFC 9111, mentions that caches may collapse requests this way.

4. Purge by tag, keep the TTL short anyway

Edits and blocks must reach the edge. Purging by URL works for one link, but Snip often needs to clear groups: all of an owner's links when their account is suspended for phishing. So each response carries surrogate keys (tags): link-x7Kp and owner-4821 above. One purge of owner-4821 clears every cached link of that owner, in every edge.

Snip purges link-x7Kp when its owner edits it and when it's blocked. It still keeps s-maxage at a minute, so a failed or delayed purge leaves a link stale for a minute at most: the same "TTL as a backstop" rule as 06.04 Invalidation and staleness.

5. Count the clicks somewhere else

Clicks answered at the edge never reach Snip's servers, so the click queue from 02.06 Async workers and queues doesn't see them. Snip switches its counting to the CDN's request logs, which the provider delivers in batches every few minutes. Workers read them into the same click pipeline. Dashboards are a few minutes behind, which Snip's staleness table already allows (06.04 Invalidation and staleness). (The alternative, a small program running at the edge that records each click, is more immediate and more work to run.)

Recap

Interview questions