🗺️Design Patterns·6 min read

CDN for Static Content

Serve static assets from edge nodes near users to slash latency and origin load.

A CDN is the default pattern for serving static content at scale: images, JavaScript bundles, CSS, fonts, downloads, video chunks, and public documents. Instead of making every user cross the internet to your origin, you cache bytes at edge locations near users and let those edges absorb the repeated reads.

🔭Think of it like…

A bakery could ship every croissant from one central kitchen, but the morning line would be terrible and the delivery vans would melt down. Instead, it stocks neighborhood shops before rush hour. Customers buy nearby, the central kitchen handles fewer trips, and the popular items stay close to demand.

When to apply a CDN in a design

Add a CDN when the same bytes are requested many times, users are spread across regions, or origin bandwidth is becoming part of your cost and latency story. In interviews and architecture reviews, this is usually a pattern decision rather than a product feature: you are deciding where repeated reads should terminate.

Signal	CDN is a good fit	CDN is not the first move
Content shape	Static or slowly changing bytes: images, bundles, video segments	Per-user JSON assembled uniquely for every request
Audience	Many users request the same object from many geographies	Tiny internal tool used from one office
Freshness	Seconds to hours of staleness is acceptable or objects are versioned	Every read must reflect the latest write immediately
Access control	Public assets or cacheable private assets with signed URLs/cookies	Highly personalized responses with object-level authorization

The decision frame

Use a CDN to remove static bytes from the hot path of your application and origin. Keep request-specific business logic in your app; push repeatable byte delivery to the edge.

How edge caching works

A user requests an asset such as /assets/app.abcd1234.js. DNS or anycast routes the request to a nearby edge. If that edge has a fresh cached copy, it returns the response immediately. If it misses, it fetches from the origin, stores the response according to cache rules, and returns the bytes to the user.

request path through a CDN

Browser
  GET /images/p/42.jpg
    ↓
Nearest CDN edge
  cache lookup by key: host + path + selected query/header values
    ├─ HIT  → return bytes in ~10-50 ms
    └─ MISS → fetch from origin (S3/app), store with TTL, return bytes

Origin sees only misses, revalidations, and purges instead of every read.

Static assets: bundled JS/CSS, images, thumbnails, fonts, and downloads are ideal because the response is byte-identical for many users.
Video chunks: HLS/DASH segments are usually immutable files, so a viral video can be served mostly from edge caches.
Origin offload: a high hit ratio means your origin, database, and object store handle far fewer requests and less bandwidth.

Mechanics live in the building block

This lesson focuses on the design pattern and decision. For more detail on PoPs, anycast, origin shield, and HTTP caching mechanics, read the content delivery networks building block.

Cache key, TTL, and versioning

A CDN cache is only as good as its cache key. The key tells the edge which requests are equivalent. A common safe default is host plus path plus selected query parameters. Be careful with headers and cookies: including too many values makes every request unique and destroys the hit ratio.

cache-control for immutable static assets

GET /assets/app.4f3a9c.js

Cache-Control: public, max-age=31536000, immutable

// The filename contains the content hash.
// Deploying new code creates /assets/app.91b2d0.js, so the old URL can live forever.

TTL is a product and operations choice

Strategy	How it works	Best for
Short TTL	Edges refresh frequently, for example every 30 seconds	Assets that change often and tolerate origin revalidation
Long TTL with versioned URL	URL changes whenever bytes change	Build artifacts, thumbnails, video chunks, public downloads
No-store or private	Do not cache at shared edges	Sensitive or uniquely personalized responses

For static assets, prefer versioned URLs or content-hashed filenames. It is cleaner to publish a new URL than to make every edge forget the old one at the same instant.

Invalidation, purge, and signed URLs

Cache invalidation is the main price you pay for edge performance. If you overwrite /logo.png while edges still have the old object, users may see stale bytes until TTL expires or you purge the cache. That is why immutable, versioned URLs are the happy path.

Purge by URL: tell the CDN to evict one or more objects. Useful for emergency takedowns, but slow or rate-limited at huge scale.
Purge by tag or surrogate key: group related objects, such as all thumbnails for one post, then invalidate the group.
Version instead of purge: change /avatar/u42/v7.jpg to /avatar/u42/v8.jpg and let old cached bytes expire naturally.

Private but cacheable objects need access control that does not destroy cacheability. Use signed CDN URLs or signed cookies when many authorized users can share the same cached bytes. For one-off private uploads and downloads, pair this pattern with presigned blob URLs.

Unique presigned origin URLs can hurt caching

If every request has a different signature in the query string, the CDN may treat every request as a different object. For popular private media, prefer stable object URLs gated by CDN signing so the edge can still reuse the cached bytes.

Pull vs push and dynamic acceleration

Most web products use a pull CDN: the edge pulls from your origin on a miss. A push CDN preloads objects into the CDN through an upload or publishing workflow. Both are valid; the choice is about workflow, predictability, and how painful misses are.

Mode	How content arrives	Use when
Pull	Edge fetches from origin on first request	Large catalog, unpredictable popularity, simpler operations
Push	Publisher uploads or prewarms content before users ask	Known launches, software downloads, premium video releases
Dynamic acceleration	CDN optimizes TLS, routing, TCP reuse, and sometimes edge compute	APIs that cannot be cached but benefit from faster network paths

Dynamic acceleration is not the same as caching. The response may still be generated by your application on every request, but the CDN can reduce connection setup, route around congested networks, terminate TLS close to the user, and reuse long-lived connections to the origin.

Design for miss storms

Popular content often expires everywhere at once. Use origin shield, TTL jitter, stale-while-revalidate, or prewarming so thousands of edges do not stampede the origin simultaneously.

Edge cases and gotchas

Cache key explosion: including all query parameters, cookies, or user-agent headers can turn one asset into millions of cache entries.
Stale data: users can see old bytes until TTL or purge completes. Version URLs for assets where correctness matters.
Authorization leaks: never cache private responses as public unless the URL or cookie signing model is explicitly designed for shared edge caching.
Range requests: large downloads and video seeking rely on byte ranges. Make sure your CDN and origin both support them.
Observability: track hit ratio, origin offload, edge latency, purge time, and top cache-miss URLs. A CDN without metrics is hard to tune.

Key takeaways

Apply a CDN when many users repeatedly fetch the same static or slowly changing bytes, especially across regions.
Edges serve cache hits close to users and fetch misses from the origin, dramatically reducing origin bandwidth and latency.
Cache key design and TTL policy determine hit ratio; versioned immutable URLs are the cleanest invalidation strategy.
Use signed CDN URLs or cookies for cacheable private content; one-off presigned blob URLs are better for direct private transfer.
Pull CDNs fetch on demand, push CDNs preload known content, and dynamic acceleration improves network paths even when responses are not cacheable.

Introduce it when the same static or slowly changing bytes are requested repeatedly, users are geographically distributed, or origin bandwidth and latency are becoming bottlenecks. Keep personalized business logic in the application and move repeatable byte delivery to the edge.

They let you cache assets for a very long time because the URL changes whenever the bytes change. The old file can remain cached safely while a new deploy references a new filename.

CDN signing authorizes access while keeping a stable cacheable object at the edge. An origin presigned URL is often unique per request and is best for direct private transfer to or from object storage, where cache reuse is not the goal.

Finished this lesson?

Mark it complete to track your progress through the workbook.