Why architecture matters here
The architecture matters because distance is the dominant latency cost and the CDN is the only lever that addresses it directly. Backend optimizations shave milliseconds; serving from an edge a continent closer than the origin shaves hundreds. For a global audience, the difference between a request that crosses an ocean and one answered from a nearby PoP is the difference between a page that feels instant and one that feels sluggish, and it applies to every cacheable byte — images, scripts, stylesheets, videos, API responses. No single origin location can be close to everyone; a network of edge caches can. That is the whole reason CDNs exist, and it is why static and semi-static content should almost always be served through one.
It matters because origin protection is as valuable as latency. Every cache hit is a request your backend does not have to handle, which means the CDN absorbs the bulk of read traffic — often the overwhelming majority — before it ever reaches your servers. This slashes the compute and bandwidth your origin must provision, flattens traffic spikes (a viral surge is served largely from the edge), and forms a first line of defense against volumetric load. An origin that would buckle under direct global traffic sits comfortably behind a CDN serving ninety-plus percent of requests from cache. The architecture converts origin capacity from something sized for peak global demand into something sized for the miss rate.
The architecture matters, too, because the cache key is a correctness boundary, not just a performance detail. The key — typically host plus path plus a chosen set of query parameters and headers — defines what the CDN treats as 'the same object.' Get it too coarse and you serve one variant when another was requested, or leak personalized content across users who share a key. Get it too fine (keying on a cache-busting parameter or a per-user header) and every request becomes a unique object, the hit ratio collapses to zero, and the CDN degrades into an expensive pass-through. The key is where caching correctness and caching efficiency are both decided, and designing it deliberately is the most consequential CDN decision.
Finally, it matters because freshness is a distributed-cache problem with no perfect answer, and the architecture forces you to choose your trade-off explicitly. Cached content can go stale the instant the origin changes, and a CDN spread across the globe cannot update every edge instantly. TTLs let you bound staleness by time; revalidation lets an edge cheaply confirm content is still current; invalidation lets you purge content on demand when you deploy. Each has a cost and a latency, and choosing among them — long TTLs for immutable assets, short TTLs or revalidation for changing content, explicit invalidation for deploys — is how you balance serve-from-cache speed against the risk of serving something out of date. A CDN with no freshness strategy is a CDN that will eventually serve the wrong thing.
The architecture: every piece explained
Top row: the request path. A user anywhere in the world makes a request that, by anycast, lands at the nearest Google edge PoP cache. If the object is cached and fresh there, the PoP serves it directly — a hit — and the flow ends without touching anything deeper. On a miss, the request proceeds through the global HTTPS load balancer, the anycast front door on which Cloud CDN is enabled, to the origin backend — a Cloud Storage bucket, a Compute Engine managed instance group, or a GKE service. The backend's response flows back out, is served to the user, and is stored at the edge for subsequent requests. The defining property is that a hit never reaches the load balancer or origin at all; only misses do.
Middle row: what makes an object cacheable and identifiable. The cache key determines what counts as the same object — by default the host and full path, optionally including selected query parameters and headers, and deliberately excluding the ones that do not change the response. The TTL and Cache-Control rules govern freshness: the origin's Cache-Control headers (and configurable default/override TTLs) say how long an edge may serve an object before it is considered stale. When an object is stale, the edge does not necessarily refetch the whole thing — it can revalidate using an ETag or Last-Modified with an If-None-Match/If-Modified-Since request; if the origin replies 304 Not Modified, the edge refreshes the object's freshness without transferring the body again. And invalidation lets you explicitly purge cached content — on a deploy, for instance — so the edge stops serving a superseded version.
Bottom-left: protecting the origin under load. When a popular object expires or is not yet cached and many users request it at once, a naive cache would send every one of those requests to the origin simultaneously — a cache-fill collapse (thundering herd). Cloud CDN uses request collapsing so that a single fetch to the origin fills the cache while the other concurrent requests wait for that fill rather than each hitting the backend. The origin sees one miss, not thousands, which is precisely the protection that lets a modest backend sit behind global traffic.
Bottom-right and ops: private content and the operating disciplines. Not everything cacheable is public; signed URLs and signed cookies let you cache content while restricting who may retrieve it, so even private assets get edge performance without being world-readable. The ops strip names the levers that keep the whole system honest: set correct cacheability headers so the right things are cached for the right duration; keep cache-key hygiene so the key is neither so coarse it leaks nor so fine it never hits; monitor the cache hit ratio as the primary health metric; and manage staleness on deploy through TTLs, versioned URLs, or invalidation so a release is actually visible to users.
End-to-end flow
Trace a media-heavy web application served through Cloud CDN, from a first-ever request through a cache hit, a deploy, and a traffic spike.
A cold request: the first user in Tokyo requests the site's main stylesheet. It is not yet cached at the Tokyo PoP, so this is a miss. The request travels through the global HTTPS load balancer to the origin — a Cloud Storage bucket — which returns the stylesheet with a Cache-Control: max-age=86400 header and an ETag. The edge serves it to the user and stores it under a cache key of host plus path. That one user paid the full origin round-trip; no one else in the region will.
A warm hit: seconds later, a second Tokyo user requests the same stylesheet. The Tokyo PoP has it cached and within its TTL, so it serves the object directly from the edge in a few milliseconds — the request never reaches the load balancer or the bucket. Across the day, as more users in each region request the asset, each region's first request fills that region's edge and every subsequent one is a local hit. The origin serves a handful of cold fills per region and nothing more; the hit ratio for this immutable asset climbs toward one.
Freshness and revalidation: an API response cached with a short TTL goes stale after its max-age. On the next request the edge revalidates rather than blindly refetching: it sends an If-None-Match with the stored ETag. The origin, seeing the content unchanged, replies 304 Not Modified with no body, and the edge refreshes the object's freshness cheaply — a tiny conditional request instead of a full transfer. Had the content changed, the origin would have returned the new body with a new ETag, and the edge would have cached that.
A deploy: the team ships a new stylesheet. Because the old one is cached at edges worldwide with a 24-hour TTL, users would keep getting the old version for up to a day. Two standard fixes apply: the robust one is versioned URLs — the new stylesheet ships at a new path (a content hash in the filename), so it is a different cache key and is fetched fresh while the old key harmlessly ages out. Where the URL cannot change, the team issues a cache invalidation to purge the object across the CDN so the next request refills from origin. Either way, the deploy becomes visible; forgetting both is exactly how a shipped fix stays invisible for a day.
A traffic spike: a promotion drives a sudden surge for a single large asset that happens to have just expired at several PoPs. Rather than thousands of simultaneous origin fetches, request collapsing sends one fill per PoP and holds the concurrent requests until it completes, so the Cloud Storage origin sees a trickle of fills instead of a stampede. The spike is absorbed almost entirely at the edge, the origin stays comfortable, and users get fast responses. What made the whole day work was cacheability set correctly, keys kept clean, freshness governed by TTL and revalidation, and deploys handled by versioning — the CDN did its job because its correctness controls were designed, not defaulted.