Intermediate System design concept · Handling Scale & Bottlenecks · 18 mins read

Content Delivery

CDNs move static and cacheable content physically closer to users so requests never have to cross the whole planet.

Open the interactive lesson See it in Design Notification System

CDN Fundamentals

Understand how CDNs place cached content near users to cut latency and shield the origin.

Intuition

If every asset request travels to one origin region, distant users wait longer and the origin wastes capacity serving the same files again and again. A CDN places cacheable reads near users. That improves latency for common assets and frees the origin for dynamic work.

Mental Model

A CDN is a distributed edge cache in front of the origin. A nearby PoP serves a hit locally; on a miss it fetches from origin, stores the result under cache rules, and makes the next request cheaper. Think of it like: The origin is a warehouse and CDN PoPs are neighborhood lockers. Filling a locker once is slower, but later pickups stay local.

Building Blocks

Edge PoP: A point of presence is the CDN site that handles the user request and stores hot objects. Its purpose is to shorten the path for repeated reads.
Origin Server: The origin is the source of truth. Every cold miss, revalidation, and uncached request still depends on it.
Cache Key: The cache key decides when two requests may share one stored object. Keys that are too broad risk wrong content; keys that are too narrow kill hit rate.
TTL and Invalidation: TTL controls reuse time, while purges or versioned URLs handle updates before expiry. Together they define the freshness story.

Definitions

Content Delivery Network (CDN)

A distributed edge network that caches and serves content closer to users than the origin can.

Best for repeated, cacheable reads such as assets and media segments.
Its value is lower latency plus origin offload.

Point of Presence (PoP)

A physical edge location that handles requests for nearby users.

PoPs are where cache hits become fast.
They matter most for global audiences far from origin.

Cache Hit

A request the edge can satisfy locally without contacting origin.

Hits reduce both latency and origin load.
They are valuable only when the cached object is still correct.

TTL (Time To Live)

The time window during which a cached object may be reused before revalidation or refetch.

Long TTLs improve offload and hit rate.
Short TTLs reduce stale windows but increase origin traffic.

Patterns

Static Asset Acceleration — Use for images, CSS, JavaScript bundles, fonts, and downloads requested by many users.
Cacheable Public GETs — Use for read-only endpoints where a short stale window is acceptable and the cache key is safe.

Strategies

Version Immutable Assets When: Use when the build system can generate unique filenames per release. How: Publish changed files under new URLs, then use long TTLs because freshness comes from the path, not frequent expiry. Example: app.5c7a1.js can be cached for a year because any code change creates a new filename.
Separate Cacheable and Personalized Paths When: Use when part of the site is public and part is user-specific. How: Cache assets and public GET routes aggressively while bypassing account, checkout, and session-dependent responses. Example: A site caches /assets/* and /catalog/* but bypasses /me and /checkout.

Freshness Is the Hard Part

Latency wins are straightforward; correctness is harder. A CDN is only helpful when the cache key is right and the reuse window matches how often the content changes.

A practical request path is: route to edge, compute cache key, check object age, then either serve, revalidate, or refetch. Most CDN mistakes come from those middle steps, not from forgetting to add an edge at all.

Tradeoffs

Decision	Upside	Downside
Long TTL vs Short TTL	Long TTLs raise hit rate and reduce origin cost. Short TTLs keep content fresher.	Long TTLs need stronger invalidation. Short TTLs send more traffic back to origin.
Broad Caching vs Conservative Caching	Broad caching captures more repeated traffic. Conservative caching lowers correctness risk.	Broad caching needs disciplined cache keys. Conservative caching leaves speed gains unused.
More Edge Reach vs Higher Cost	A larger edge footprint improves latency and resilience for global users.	Extra footprint costs more and helps less when traffic is already regional.

Real World

System	How it's used
Cloudflare	Cloudflare caches assets, media, and selected public responses on an anycast edge, reducing repeated origin reads.
AWS CloudFront	CloudFront commonly fronts S3 or app origins for static assets and streaming objects, usually paired with versioned paths and TTL tuning.

Interview

Questions interviewers ask

What problems does a CDN solve besides faster image loads?
Walk through the request path for a cache hit versus a cache miss.
Which content types are safe to cache aggressively, and which are not?
How do TTLs, cache keys, and invalidation work together?

What a strong answer covers

A strong answer explains the edge-hit path, the miss path to origin, and how correctness depends on cache keys, TTLs, and invalidation.

Common traps

Reducing CDN discussion to “it makes images faster.”
Talking about hit rate without freshness or cache-key correctness.
Caching personalized responses without clear bypass rules.

Quiz

What is the main architectural reason a CDN reduces origin load?

It compresses database tables at the origin
It serves repeated cacheable requests from edge locations instead of forwarding all of them to origin
It removes the need for DNS entirely
It turns every request into a write-behind queue

A CDN helps when many users ask for the same cacheable object. Edge hits terminate those reads locally, so the origin no longer handles every repeated request.

Which request path describes a cache miss at the edge?

Client to edge to origin to edge to client
Client to origin only, bypassing the edge
Client to database replica directly
Client to edge to another client

On a miss, the edge has to fetch the object from origin or an upper tier before returning it. That extra round trip is why miss latency is always worse than hit latency.

Why are versioned static asset filenames such as app.9fd2.js a best practice with CDNs?

They force every request to miss so users always see the newest file
They let browsers skip TLS handshakes
They allow very long TTLs because a changed asset gets a new URL instead of overwriting the old one
They make anycast routing deterministic

Versioned URLs separate freshness from expiry. You can cache the old URL aggressively because new content is published under a new path, not the same one.

At a conceptual level, what does anycast contribute to CDN performance?

It guarantees all users will hit the exact same edge server
It encrypts cached objects before they are stored
It makes cache invalidation unnecessary
It routes users toward a nearby edge location by advertising the same IP from many places

Anycast is a routing trick, not a caching policy. It improves the first hop by making a globally distributed service reachable through one IP that exists in many locations.

Which content is usually the safest to cache aggressively at a CDN edge?

Personalized account pages tied to a session cookie
Payment authorization responses
Content-hashed CSS and JavaScript bundles that change only on deploy
A POST /checkout endpoint

Immutable static assets are ideal because correctness does not depend on user identity and freshness is controlled by the filename. Personalized or mutating responses should usually bypass edge caching.

Push CDN

Learn when proactively replicating content to the edge beats lazy caching on demand.

This section is part of the full PRISM roadmap, with worked examples, trade-off tables, interview questions and a quiz.

Unlock the full lesson

Pull CDN

Understand how pull-through edge caching fetches content on first demand and why that simplicity is powerful.