Skip to content
System design course
Ch.3 · Trade-offs that define a design·concept ·7 min read

CDN vs serving from origin

Cache content at edge locations near users, or serve everything from your own servers — a trade of latency and scale against cost, control, and freshness.


The question

When a user in Sydney requests content hosted in Virginia, do they reach across the planet to your origin servers, or hit a CDN edge node a few miles away? A Content Delivery Network is a globally distributed set of caching servers; the choice is whether to put one in front of your origin.

Serving from origin

Every request goes straight to your own servers.

  • Wins: full control and freshness (always the latest, no cache to invalidate); simplest architecture; no third-party cost or config; necessary for truly dynamic, per-user, or sensitive responses.
  • Costs: latency grows with distance (one slow round trip per asset, × many assets per page); your origin absorbs all traffic (bandwidth + load); a traffic spike or a viral asset can overwhelm you; no geographic redundancy.

Serving via a CDN

Cache content at edge locations worldwide; users are routed (via anycast/DNS) to the nearest one.

  • Wins: low latency (content served near the user); massive offload — the CDN absorbs the bulk of reads so your origin sees a trickle; scales to huge traffic and flash crowds; DDoS absorption and TLS at the edge; survives origin hiccups by serving cached copies.
  • Costs: cache invalidation/staleness — updates must propagate (TTLs, purges, versioned URLs like app.v7.js); money (CDN bandwidth, though often cheaper than origin egress at scale); another system to configure; least useful for highly dynamic, personalized responses.

What belongs on a CDN

  • Great fit (static / cacheable): images, video, CSS/JS bundles, fonts, downloads, and any content identical for many users. Cache for a long TTL with versioned filenames so a deploy = a new URL (no invalidation needed).
  • Poor fit (dynamic / personal): per-user dashboards, real-time data, authenticated responses — serve from origin (or use the CDN only as a routing/TLS layer).
  • In between: semi-dynamic pages via short TTLs or stale-while-revalidate; modern CDNs also run edge compute to personalize at the edge.

Push vs pull CDNs

  • Pull — the CDN fetches from origin on the first request for an asset and caches it (lazy; easy to operate; first user pays the miss). The default.
  • Push — you upload assets to the CDN ahead of time (good for large, known files like video; you manage what’s there).

The interview cue

In nearly any design serving images, video, or static assets to a wide audience, put a CDN in front: “Static assets and media go through a CDN with long TTLs and versioned URLs — it serves users from the edge and offloads ~95% of read bandwidth from origin. Dynamic, personalized API responses still hit origin (behind its own cache).” Naming what to cache, the invalidation strategy (versioning/TTL), and the origin-offload benefit is the signal.