Stackbook Logo
scalingestablished · medium operational burden

CDN Edge Caching

Also known as: edge-cache, content-delivery-network

Intent

Serve cacheable responses from points of presence near users to cut latency and offload the origin.

Problem

Every request travels to a central origin, adding round-trip latency for distant users and concentrating load on origin servers. Traffic spikes for popular content overwhelm the origin even though responses rarely change.

Forces

  • •Physical distance adds unavoidable latency
  • •Origin capacity is expensive and finite
  • •Content freshness requirements vary per resource
  • •Personalized responses cannot be shared across users

Solution

Overview

A CDN moves cacheable content closer to users. Each point of presence stores responses and answers repeat requests without contacting the origin, which reduces both latency and origin load. The two numbers that matter are cache hit ratio and time to first byte.

How it works

Client -> Edge PoP -> Regional shield -> Origin
          (hit: return)   (hit: return)   (miss: render + store)

The origin controls behavior with headers:

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=30

Here browsers keep the object for 60 seconds, shared caches for 10 minutes, and the edge may serve a stale copy for 30 more seconds while it revalidates in the background. A shield tier collapses misses from many edges into one origin request. Immutable assets use fingerprinted file names such as app.3f9a1c.js with a one-year max-age, so no purge is ever needed.

Pitfalls

  • Caching responses that vary by cookie or Authorization header without Vary or a keyed cache, leaking one user's data to another.
  • Cache keys that include tracking parameters, which fragments the cache and destroys the hit ratio.
  • Relying on purge for correctness. Purges propagate in seconds but are not atomic, so design for brief staleness.
  • Caching error responses (5xx) for the full TTL. Set a short negative TTL.
  • Forgetting that edge hit ratio is measured per object popularity; the long tail will always miss.

Key takeaways

  • Cache by default what is public and immutable; fingerprint assets instead of purging them.
  • Design the cache key deliberately and verify private data never enters the shared cache.
  • Use a shield tier and stale-while-revalidate to protect the origin during expiry.
  • Track hit ratio and origin offload as first-class metrics.

✓ When to Use

  • •Static assets, images, video segments and downloads
  • •Public API or HTML responses that tolerate seconds to minutes of staleness
  • •Global audiences far from a single origin region

✗ When Not to Use

  • •Per-user private responses without careful cache-key design
  • •Data that must be strongly consistent on every read
  • •Low-traffic sites where hit ratio will stay near zero

Pros

  • +Large latency reduction for distant users
  • +Origin load drops by the hit ratio
  • +Absorbs traffic spikes and some DDoS volume

Cons

  • −Invalidation is slow and eventually consistent across edges
  • −Cache-key mistakes can leak private content
  • −Another vendor and layer to debug

Cost Profile

Infrastructure

Per-GB egress and request fees; offsets origin cost

Operational

Medium: tune TTLs, purges and cache keys

Cognitive

Medium: layered cache semantics

Failure Modes

  • Private or user-specific response cached and served to others

  • Stale content persists after a failed purge

  • Origin overwhelmed when a popular object expires everywhere at once

Real-World Examples

Alternatives

    Related Patterns

    • caching
    • load-balancing

    Competency Domains

    distribution communicationeconomics evolution