What a CDN Is, and Its Requirements

Why this matters: "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.

Key takeaway

A content delivery network (CDN) is a distributed system of servers placed across geographic locations to improve the speed and reliability of content delivery. Rather than relying on a single origin, it uses a network of proxy servers closer to end users.

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.

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

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 the DNS chapter, and GSLB from the Load Balancers chapter. This chapter uses them rather than re-deriving them.