Cloud CDN

Edge caching on Google's global network, fronted by the load balancer.

Problem it solves: Serving large or popular content from a single origin is slow and expensive in egress.

Where it sits: Between clients and the origin load balancer.

When to use

  • Read-heavy static assets, media, and cacheable API responses.

When not to use

  • Highly personalised or rapidly changing responses with no shared cache key.

Failure modes

  • Cache stampede on purge or expiry overloads the origin.
  • Misconfigured cache keys leak or fragment content.

Metrics to watch

  • Edge hit ratio (%)
  • Origin offload (req/s saved)
  • Edge latency (ms)

Alternatives

  • Origin shield
  • Application cache

Configuration in Labs (illustrative defaults)

  • Steady-state hit ratio (0–1) = 0.9 — Fraction of requests served from the cache once warm. Misses go downstream.
  • Hit latency (ms) = 15 — Time to answer a request that hits the cache.
  • Warm-up time (s) = 30 — When the cache starts cold, the hit ratio grows linearly to its steady-state value over this time.

Vendor examples (pattern only): Google Cloud managed service. Simulated as a generic “CDN / edge cache”.

In the guide