What a CDN Is, and Its Requirements
In one line: "CDN" and "cache" get used interchangeably and are not the same thing. Getting the distinction right — and the six operations a CDN actually performs — is what turns a vague box on your diagram into a design.
Edge servers
Those proxy servers operate at the network edge and are called edge servers. By caching content near users they:
- Reduce latency
- Conserve bandwidth
- Protect the origin server from traffic spikes
CDNs minimize the physical distance data travels by storing copies of both static and dynamic content in local data centers. That proximity reduces propagation delay and ensures sufficient bandwidth along the delivery path.
A cache and a CDN are not the same thing
A cache stores frequently accessed data closer to the application or user to reduce latency and backend load.
A CDN distributes content across geographically dispersed edge servers to reduce network latency for end users.
The difference is the axis. A cache addresses repeated work; a CDN addresses distance. A cache in your data center does nothing for a user in Cape Town — the request still crosses an ocean to reach it. Conflating them in an interview reads as not having thought about where the latency actually comes from.
The three problems addressed
| Problem | How the CDN addresses it |
|---|---|
| High latency | Edge servers shorten the physical distance between content and user, reducing network congestion and propagation delay |
| Data-intensive loads | The origin sends data to the CDN once; the CDN then distributes it to many users, so the origin never sends a copy per user |
| Resource scarcity | CDNs handle the majority of traffic for popular content, offloading origin servers and sharing load across distributed components |
Does a CDN cache everything?
Not likely. A CDN caches a considerable portion of content based on its capabilities — mostly static content.
It also depends on volume. Netflix might store more than 90% of its movies in the CDN, whereas that is not feasible for a service like YouTube given the sheer size of its catalogue.
Functional requirements
Six operations:
| Operation | What it does |
|---|---|
| Retrieve | Fetch content from origin servers, depending on the CDN model |
| Request | Proxy servers accept and respond to user requests for content |
| Deliver | In a push model, origin servers send content directly to CDN proxies |
| Search | Efficiently query the infrastructure to locate cached or stored content |
| Update | Propagate content updates to peer proxy servers in a PoP — often via a replication script |
| Delete | Remove cached entries via TTL or purge requests, for static and dynamic content |
Note that Retrieve and Deliver are the same content movement in opposite directions — pull versus push. That distinction becomes Lesson 4.
Non-functional requirements
| Requirement | Target |
|---|---|
| Performance | Minimize latency for the fastest possible response times |
| Availability | Remain operational during traffic spikes or attacks such as DDoS |
| Scalability | Support horizontal scaling to handle increasing user load |
| Reliability and security | Eliminate single points of failure and protect hosted content from malicious attacks |
Security is a first-class requirement here, not an afterthought
A CDN sits in front of everything, which makes it both the first line of defense and a high-value target. Because it terminates enormous traffic volume close to users, it is the natural place to absorb a DDoS — the scrubber servers in the next lesson exist for exactly this.
That is why "availability during attacks" appears in the requirements rather than as a later optimization.
Building blocks
The design reuses two components you have already built:
- DNS — maps human-friendly domain names to the IP address of the appropriate proxy server.
- Load balancers — distribute requests among operational proxy servers.
Both chapters already covered the mechanisms this design leans on: DNS-based traffic steering and anycast from DNS, and GSLB from load balancing. This chapter uses them rather than re-deriving them.
Key takeaway
A CDN is a distance solution, not a repetition solution. Six operations, four non-functional targets, and it stands on DNS for routing and load balancers for distribution within each location.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "A CDN caches static content near users." |
| L5 | Separates it from caching: "a cache fixes repeated work, a CDN fixes distance — and it also shields origin from spikes and DDoS." |
| Staff+ | Reasons about what's cacheable: "how much of the catalogue fits at the edge decides the strategy — Netflix can hold 90% of its library, YouTube can't, so one gets push and the other needs pull with long-tail handling." |
Next: the components and the workflow between them.