retrystorm · Learn · Interview practice · Glossary · Components

Home › Learn › The Edge

Chapter 15 · Caching and edge · 15 min

The Edge

Distance, CDNs, and the freshness versus speed dial.

Inkwell went international. Users in Europe and Asia love it, but profile pictures crawl for them. The servers are in Virginia, and the speed of light isn't going to change.

Inkwell's servers are fast. For users in Singapore, it barely helps, and the reason is physics.

Distance costs time

Signals in fibre travel at about two thirds of the speed of light, and real routes are longer than straight lines. A round trip from Singapore to Inkwell's servers in Virginia takes around 220 ms before the servers do any work at all. No database, cache or code change can remove it.

Before any work happens, the request has to cross the planet and back.

Inkwell users inRound trip to Virginia
New York~10 ms
London~75 ms
Singapore~220 ms

CDNs

A CDN (content delivery network) runs edge locations in cities all over the world, close to users. Put it in front of Inkwell: requests go to the nearest edge first.

  • If the edge has a copy of the picture, it answers right there: a hit, typically 10 to 20 ms away.
  • If not, the request travels on to Inkwell's servers (the origin), pays the long trip, and the edge keeps the response for next time.

Hits are answered nearby; only misses make the long trip.

A CDN is a cache that lives near users rather than near the database. Everything from the caching chapter applies: hit rates, skew, staleness.

Each edge keeps its own copies. A picture cached in London is still a miss the first time someone in Singapore asks for it, so every edge pays its own first view, and a picture viewed now and then in each region misses far more often than one global cache would. Most CDNs offer tiered caching (an origin shield): an edge that misses asks one regional cache before the origin, so the origin sees one fetch instead of one per edge. It saves the origin load, not the distance.

TTL and purging

Each cached copy has a TTL; when it runs out, the next request goes back to the origin.

The usual way to change a file on a CDN is to give the new version a new URL: avatar-v2.jpg, or a name made from a hash of its bytes. Nothing at the old URL ever changes, so the edge can keep every copy for a year and never needs a purge. Scripts, styles and most pictures are served this way.

Some content can't change its URL: an API response, a page, a count, or Inkwell's profile pictures, which the apps ask for at one fixed URL per user. When that content changes, the app can ask the CDN to purge its copies, through the CDN's purge API, or keep serving the old one until the TTL runs out (ttl_only in retrystorm). A purge isn't instant everywhere: the edge the upload came through drops its copy at once, and the purge reaches the others later, from a fraction of a second to minutes depending on the CDN (about a second in retrystorm). Until then, those edges keep serving the old copy. A purge also can't clear the copies browsers keep under their own max-age, so purged content usually gets a short browser max-age.

That's a dial between freshness and speed. Purging keeps pictures fresh, but a picture that changes often keeps being dropped, and its views go to the origin. Serving until the TTL keeps the edge full, with pictures up to one TTL old.

Medians, tails and what a CDN can't fix

A CDN moves the median a lot: most requests become hits close to users. The tail (p95, p99) is a different story, because it's made of the requests the edge couldn't answer. Those still pay the full distance:

  • Uploads (writes) always travel to the origin.
  • Misses, including the very first view of each picture, and every view after a purge or an expired TTL.
  • Content that is different for every user and can't be shared at all.

That last point decides what goes on a CDN. Static content, the same bytes for everyone (pictures, scripts, a public post), caches well. Dynamic content, built per user (a feed, a cart), mostly can't, unless it's split into a shared part and a small personal part. An edge keys each copy by the URL (its cache key), so two URLs for the same picture are cached twice, and a user id in the URL makes every copy private.

However fast the servers get, distance adds time that no code can remove.

In the wild

The ideas in this chapter, and where you'll meet them in real systems and interviews:

IdeaWhere you'll meet it
CDNsCloudflare, Akamai, Amazon CloudFront, Fastly
TTLs and purgesCache-Control headers, each CDN's purge API
Tiered cachingCloudFront Origin Shield, Cloudflare Tiered Cache, Fastly shielding

Your practice

Serve the World: bring Inkwell's profile pictures close to users on three continents, then tune the edge so almost everyone is fast without pictures going too stale.

Key takeaways

  • Distance adds round-trip time that no server or code change can remove.
  • A CDN answers hits from an edge near the user and sends misses to the origin.
  • Changed files get a new URL. At a fixed URL, purging keeps copies fresh; serving until the TTL keeps the edge full.
  • A CDN moves the median; writes and misses still pay the full trip, so the tail stays.

Read first

  • Caching

Practise it

  • Serve the World: Profile pictures for users on three continents. Bring them close with a CDN.

Terms

  • Cache key: What a cache files each copy under, usually the URL.
  • CDN: A content delivery network: caches in cities around the world, close to users.
  • Edge and origin: The edge is a CDN location near users; the origin is your own servers behind it.
  • Origin shield: A CDN layer between the edges and the origin, so many edges missing the same file cost the origin one fetch.
  • Purge: Removing a CDN's cached copy before its TTL runs out, usually after the content changed. It takes from a fraction of a second to minutes to reach every edge, depending on the CDN.
  • Static and dynamic content: Static content is the same for everyone and caches well; dynamic content is built per user.
About · Contact · Privacy · Terms of use