How to Design with a CDN

A content delivery network (CDN) is a globally distributed set of edge servers that cache and serve content from locations close to the user. For any system with images, videos, or static assets, the CDN is the single biggest latency win available, and senior interviewers expect it to appear in your architecture automatically.

1. Why a CDN Matters

• Latency: serving a video from Mumbai instead of from a US origin cuts RTT from >200ms to tens of ms.
• Offload: the origin server never sees requests for cached popular content, so backend capacity shrinks.
• Resilience: absorbs traffic spikes and DDoS bursts at the edge.
• Cost: cached bytes are far cheaper than origin bandwidth.

2. High-Level Architecture

graph LR
    U["User (Mumbai)"] --> E1["Edge (BOM)"]
    U2["User (London)"] --> E2["Edge (LHR)"]
    E1 -->|"miss"| O["Origin"]
    E2 -->|"miss"| O
    O --> S["Object store / DB"]
    style E1 fill:#D97A2B,stroke:#B86418,color:#fff
    style E2 fill:#D97A2B,stroke:#B86418,color:#fff
    style O fill:#FAF6EE,stroke:#E8DFC8

3. Pull CDN vs Push CDN

Pull (on-demand)

The edge fetches the origin on the first miss (like cache-aside). Automatic, no pre-upload, good for images and HTML that change over time. Downsides: first request per region is slower, and origin must handle the miss stream.

Push (proactive)

You upload files to the edge ahead of time (like write-through). Eliminates cold-start misses, ideal for pre-known large files such as video courses or app releases. Downsides: you must know the content in advance and pay for storage everywhere.

4. TTL and Cache Invalidation

Three strategies, in order of reliability:

1. Content-hashed URLs: app.3f2a9.css changes its URL when content changes, so there is never stale cache. This is the industry default for deployable assets.
2. TTL (max-age / s-maxage): let the cache expire quickly for content that changes, longer for immutable files. Tune per asset class.
3. API purge: explicitly evict a URL or path; potent but racy if in-flight variants are cached, and every purge is a network call.

For personalized content, either cache per-user with cookies as the cache key or bypass the CDN entirely. The line between "cachable static" and "dynamic" is decided here.

5. What Belongs on the CDN

• Yes: images, video thumbnails, JS/CSS bundles, fonts, static HTML, audio.
• Conditional: HTML with per-user sidebars (use edge-side includes or a short TTL).
• No: account balances, session state, API responses that are user-specific and live.

Fallback: combine with the caching strategies tutorial's Redis layer, which caches the dynamic parts the CDN cannot.

6. Video Streaming with a CDN

Streaming is where CDNs really shine: chunk the video into segments, store them on object storage, and let the CDN serve the hottest segments from the edge. Bitrate variants let adaptive players switch quality. This is the exact approach behind the Netflix streaming case study.

7. Common Interview Mistakes

• Never mentioning a CDN in a media-heavy design : obvious omission.
• Putting dynamic, personalized API data on the CDN and fighting invalidation forever.
• Not knowing pull vs push trade-offs when asked.
• Claiming CDN removes the need for Redis caching of dynamic content.
• Ignoring global regions or how DNS routes a user to the nearest edge.

8. Summary: Key Decisions

Classify content static vs dynamic, front it with a pull CDN for media and assets, use content-hashed URLs or TTL for freshness, and keep the dynamic layer on Redis + origin. Answering in that order covers the whole question.

Frequently Asked Questions

Related Tutorials

• Caching Strategies : CDN is just a geographically distributed cache.
• Load Balancing : edge routing before the origin tier.
• Consistent Hashing : how edge key-routing scales.
• Netflix streaming case study : CDNs in production-scale media.