Content Delivery and Edge Caching

A content delivery network caches responses at edge locations distributed around the world. When a user requests something already cached nearby, it is served from that location rather than travelling to your origin servers.

On Google Cloud this is enabled on a backend service behind an external Application Load Balancer, which is why the two topics are usually studied together.

The benefits compound. Latency drops because content travels a shorter distance. Origin load falls, often dramatically, because a high cache hit ratio means most requests never reach your servers. Egress costs fall for the same reason.

There is a resilience benefit too. Cached content can continue being served during an origin problem, turning what would have been an outage into degraded functionality for a subset of users.

• Cache key — what identifies a cached entry. By default it includes the host and full path; including or excluding query parameters, headers and cookies changes hit ratio substantially.
• Time to live (TTL) — how long an entry stays valid, driven by cache-control headers from your origin or by overrides on the load balancer.
• Cache hit ratio — the proportion of requests served from cache. The single number that tells you whether the configuration is working.
• Invalidation — explicitly removing cached content before it expires, for when you publish a correction and cannot wait for the TTL.
• Cache modes — cache only what is explicitly marked cacheable, cache all static content automatically, or force caching of everything.
• Negative caching — caching error responses briefly so a failing origin is not hammered by retries.

The most reliable approach is to avoid needing invalidation. Give static assets content-hashed filenames — app.4f2a9c.js rather than app.js — and cache them for a very long time. When content changes the filename changes, so the new file is fetched and the old cached copy is simply never requested again.

• Long TTLs for versioned, immutable assets such as scripts, stylesheets and images.
• Short TTLs for HTML pages that reference those assets.
• Never cache authenticated, personalised responses at the edge unless you are certain the cache key isolates users.
• Reserve explicit invalidation for genuine mistakes rather than routine deployment.

• Serving images, video, scripts and stylesheets close to a global audience.
• Reducing origin load and egress cost for a high-traffic public site.
• Distributing software downloads and large static files internationally.
• Caching API responses that are identical for all users, such as public catalogues.
• Absorbing sudden traffic spikes from a marketing campaign without scaling the origin.