How it works
Put the CDN in front of an origin, such as object storage or an application server. A URL like media.example.com/video/42/segment-1.m4s routes through the CDN rather than directly to storage.
DNS-based routing or anycast directs the client toward a suitable edge location based on network conditions, capacity, and availability, not necessarily the geographically closest server. The edge terminates the client connection and handles the request.
The edge looks up a cache key, typically based on the hostname, path, and selected query parameters or headers. A fresh cache hit can be served without contacting the origin. Different image sizes or video renditions need distinct keys, while irrelevant tracking parameters should not fragment the cache.
On a miss, the CDN fetches from an upstream cache or the origin and may store the response for later requests. An optional shared cache layer, often called an origin shield, and request coalescing can reduce duplicate origin fetches when many edges miss on the same object.
Cache rules and HTTP headers determine whether a response is cacheable and how long it stays fresh. After expiration, the CDN can fetch it again or revalidate it using an ETag. Versioned URLs, such as /assets/app.a81f.js, allow long cache lifetimes without serving an old version at the new URL.
Private content needs authorization even when its bytes are cached. The CDN can validate signed URLs or cookies before serving a shared cached object, but this must be configured explicitly. Personalized API responses usually bypass shared caching unless the design safely separates users and permissions.
A worked example
Sizing CDN delivery for a video service
Assume 100,000 concurrent viewers each receive an average of 4 Mbps. Delivery requires about 400 Gbps before protocol overhead. Store transcoded, versioned video segments in object storage and serve them through a CDN. If the measured byte hit ratio is 95%, origin traffic is roughly 20 Gbps, not counting uploads or other workloads. That is still substantial, so use an origin shield and coalesce concurrent requests for identical segments. Keep immutable segments cacheable for a long time; give mutable manifests a shorter freshness window. For restricted videos, validate playback credentials at the edge even on cache hits. During a cold-cache launch, plan for a much lower hit ratio rather than sizing the origin only for steady state.
Trade-offs to say out loud
- Lower latency, but misses still matter
- Hits avoid an origin round trip, while cold or unpopular objects still require upstream fetches and may have worse tail latency.
- Origin savings versus delivery charges
- Caching reduces origin bandwidth and requests, but CDN egress, request fees, cache fills, and invalidations still contribute to cost.
- Freshness versus reuse
- Long TTLs improve reuse but allow older content to remain visible unless you use versioned URLs, revalidation, or purges.
- Cache efficiency versus variant correctness
- Including too many dimensions in the cache key lowers reuse, while omitting meaningful dimensions can serve the wrong content or leak private data.
- Availability versus stale responses
- Serving stale content during origin failures can preserve availability, but it is unsafe for content whose freshness or access rules must be enforced immediately.
- Edge scale versus origin overload
- Cold starts, mass expiration, or CDN failures can overwhelm the origin unless you bound refill concurrency and plan degraded behavior.
When to reach for it
- Users in multiple regions repeatedly download the same images, static assets, video segments, or files.
- Media delivery bandwidth dominates the workload, so serving every byte from application servers or origin storage is expensive.
- A popular upload or page can create a sudden spike that should mostly be absorbed outside the origin.
- Public pages or read-only responses tolerate a defined freshness window and can be safely shared across users.
- Private media needs global delivery, with explicit edge authorization and a clear access-revocation policy.
How to bring it up in the interview
- Name exactly what is cached: image variants, video segments, public HTML, or another reusable response, not simply 'all traffic goes through a CDN.' Interviewers will probe which requests still reach the application.
- Walk through both the hit and miss paths, including origin storage, cache keys, and optional shielding. Expect questions about simultaneous misses for a newly popular object.
- State a freshness contract: use versioned URLs for immutable bytes and bounded TTLs or revalidation for mutable responses. Explain how deletion differs from publishing a new version.
- Estimate delivery bandwidth and origin bandwidth separately using an explicit byte hit ratio. Track request hit ratio too, since many small hits can hide expensive large misses.
- Define private-content authorization and revocation before optimizing cache reuse. Expect follow-ups about expired signed URLs, cached browser copies, and whether an origin outage should fail closed.
Common mistakes
- Treating a CDN as durable storage or as a replacement for an origin and its recovery plan.
- Assuming every request reaches the nearest edge, every object is already cached, or a miss disappears because the CDN is large.
- Using long TTLs for mutable content without explaining versioning, invalidation, or acceptable staleness.
- Caching personalized responses under a shared key, or assuming possession of an object URL is sufficient authorization.
- Claiming a purge or signed-URL expiration recalls bytes already downloaded; purges also do not instantly remove every browser or downstream cached copy.
Where it comes up
Interview questions where content delivery networks (cdn) is part of a strong answer, and why.
- Design a video streaming service like YouTubeCDN delivery of adaptive-bitrate segments is central to playback latency, origin protection, and bandwidth economics.
- Design TikTokEdge caching and segment delivery directly affect first-frame latency and the bandwidth wasted when users quickly swipe away.
- Design InstagramCDN-backed image delivery absorbs popular-post traffic while publication rules prevent users from receiving missing or unfinished image variants.
- Design Google PhotosPrivate photo delivery requires CDN caching to work with signed access, deletion, and timely sharing revocation.
- Design Wikipedia or NotionGlobal page caching must balance fast reads with revision freshness and permission checks that prevent private content leaks.
Questions people ask
What is the difference between a CDN and a load balancer?
A load balancer distributes requests across servers or locations. A CDN adds a distributed delivery layer that can satisfy requests from edge caches without reaching your origin. CDNs also use routing and load balancing internally, so the concepts overlap but solve different parts of the design.
Can a CDN cache dynamic content and API responses?
Yes, if responses are reusable and the cache key captures every input that changes the result. Public weather responses or product descriptions may tolerate short shared-cache TTLs. Personalized or permission-sensitive responses need explicit isolation and freshness rules; otherwise, bypass shared caching.
How do you invalidate CDN caches?
For immutable assets, publish changed bytes under a new versioned or content-hashed URL. For mutable URLs, use bounded TTLs, revalidation, or a CDN purge, accounting for purge propagation time. Deleting an origin object alone does not remove cached copies, and urgent access revocation may require an authorization check at the edge.