CDN & Asset Delivery

The Problem

Users expect sub-second page loads regardless of their location. Serving assets (images, scripts, videos, API responses) from a single origin server means users far from the origin experience high latency. A Content Delivery Network (CDN) caches content at edge locations worldwide, serving users from the nearest point of presence (PoP). But CDN configuration is nuanced: choosing what to cache, setting correct cache headers, invalidating stale content, protecting the origin from thundering herds, handling dynamic content at the edge, and optimizing for Core Web Vitals — all while keeping costs manageable.

Architectural Approaches

Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Cache-Control Headers Deep Dive

The Cache-Control header is the most important lever for CDN behavior.

Key directives:

• public, max-age=31536000, immutable — Cache forever. Use for fingerprinted assets (app.a1b2c3.js). The “immutable” hint tells browsers not to revalidate even on refresh.
• public, max-age=0, must-revalidate — Always revalidate with origin. CDN stores the content but checks freshness on every request (conditional GET with ETag/If-Modified-Since).
• public, s-maxage=3600, max-age=60 — CDN caches for 1 hour, browser caches for 1 minute. Different TTLs for edge vs browser.
• private, no-store — Never cache anywhere. Use for personalized or sensitive responses.
• stale-while-revalidate=60 — Serve stale content while fetching fresh version in background. Great for API responses.

Common patterns:

• Static assets (JS, CSS, images with hash): max-age=31536000, immutable
• HTML pages: s-maxage=60, stale-while-revalidate=300 (CDN caches 1 min, serves stale for 5 min while refreshing)
• API responses: s-maxage=10, stale-while-revalidate=30 (CDN caches 10s, users always get fast response)
• User-specific data: private, no-cache or private, max-age=0

Vary header: Tells the CDN to cache separate versions based on request headers. Vary: Accept-Encoding caches gzip and brotli versions separately. Vary: Accept for content negotiation (WebP vs JPEG). Avoid Vary: Cookie — creates a separate cache entry per user, destroying cache efficiency.

Origin Shield and Tiered Caching

Without origin shield, each of 300 CDN PoPs independently fetches content from your origin on a cache miss. A popular asset could trigger 300 concurrent origin requests.

Origin shield inserts a middle tier:

1. User requests asset from nearest PoP (edge tier)
2. Edge PoP cache miss → forward to origin shield PoP (mid tier)
3. Shield PoP cache miss → forward to origin
4. Shield caches the response → all future edge misses are served from shield

Benefits:

• Origin receives at most 1 request per asset (from the shield), not 300
• Dramatically reduces origin bandwidth and compute
• Shield PoP has a much higher cache hit ratio (aggregated from all edges)
• Origin can be smaller and cheaper

Shield PoP selection: Choose a shield PoP near your origin for lowest latency. Cloudflare calls this “Tiered Cache” and auto-selects optimal shield locations. CloudFront calls it “Origin Shield” with manual region selection.

Cost consideration: Shield adds an extra CDN hop (edge → shield → origin). Slightly higher latency on cache misses (extra network hop). But the dramatically improved cache hit ratio more than compensates. Most platforms see 95%+ shield hit ratio.

Cache Invalidation Strategies

When content changes, you need the CDN to serve the new version. Several strategies:

Cache busting (fingerprinting): Include a content hash in the filename: app.a1b2c3.js. When content changes, the filename changes. Old version stays cached (never served again since nothing links to it). New version is fetched fresh. This is the best approach for static assets — no purging needed.

Cache tags (surrogate keys): Tag cached responses with metadata: Cache-Tag: product-123, category-shoes. When product 123 changes, purge all responses tagged “product-123”. Supported by Cloudflare, Fastly, and CloudFront (via Lambda@Edge). Ideal for dynamic content with known invalidation patterns.

TTL-based expiry: Set a short TTL and accept temporary staleness. Simple but imprecise. Use stale-while-revalidate to serve stale content immediately while refreshing in the background — users always get fast responses.

Purge API: Programmatically purge specific URLs or patterns. Cloudflare supports per-URL, per-tag, per-hostname, and full purge. Trigger purges from your CI/CD pipeline on deployment or from your CMS when content is published.

Soft purge (Fastly): Mark content as stale rather than deleting it. The CDN serves the stale version while fetching a fresh copy from the origin. Eliminates the “thundering herd” that happens when a purge causes all PoPs to simultaneously request from origin.

Best practice: Use fingerprinted URLs for static assets (never purge) + cache tags for dynamic content (targeted purge) + short TTL with stale-while-revalidate as a safety net.

Real-World Examples

Architectural Tradeoffs

# Learn the System Design of: CDN & Asset Delivery

You are an expert software architect and teacher. I want to understand cdn & asset delivery as a practical system design capability. (Origin shielding, cache hierarchies, purging strategies, and global content distribution).

Use the following architectural guide as a learning reference. Avoid one-size-fits-all recommendations. Keep assumptions, costs, and tradeoffs explicit.

---

import { Mermaid, ComponentList, ComponentCard, ApproachList, Approach, Example, Tradeoff } from '@/components/mdx';

## The Problem

Users expect sub-second page loads regardless of their location. Serving assets (images, scripts, videos, API responses) from a single origin server means users far from the origin experience high latency. A Content Delivery Network (CDN) caches content at edge locations worldwide, serving users from the nearest point of presence (PoP). But CDN configuration is nuanced: choosing what to cache, setting correct cache headers, invalidating stale content, protecting the origin from thundering herds, handling dynamic content at the edge, and optimizing for Core Web Vitals — all while keeping costs manageable.

## Architectural Approaches

<ApproachList>
<Approach
  name="Pull-Based CDN (Cache on First Request)"
  pros={[
    'Zero configuration for basic setup — point DNS at the CDN',
    "Only caches content that's actually requested (demand-driven)",
    'Origin only serves cache misses — dramatically reduced load',
    'Automatic geographic distribution',
  ]}
  cons={[
    'First request to each PoP hits the origin (cold cache)',
    'Cache misses during traffic spikes can overwhelm the origin',
    'Must tune cache headers carefully for correct caching behavior',
    'Dynamic content requires explicit cache rules',
  ]}
>
The CDN sits in front of your origin. On the first request for an asset, the CDN fetches it from the origin, caches it at the edge, and serves subsequent requests from cache. No proactive...

[Full prompt copied to clipboard]