Imagine opening a website from India while its servers are located in the United States.
You request an image.
Your request travels thousands of kilometers to the server, the server processes it, and the response travels all the way back to you.
It works.
But what happens when millions of users around the world do the same thing?
This is where a CDN (Content Delivery Network) comes in.
A CDN helps websites deliver content from servers that are geographically closer to users, reducing latency, improving performance, and taking load away from the main server.
In this article, we'll understand how CDNs work, why they're important, and how they're used in large-scale systems.
What Is a CDN?
A Content Delivery Network is a globally distributed network of servers that stores and delivers frequently requested content closer to users.
Without a CDN, requests might look like this:
User
↓
Main Server
↓
Content
With a CDN, a distributed layer is added between users and the origin server:
┌── CDN Edge Server ── User (India)
│
Origin Server ────┼── CDN Edge Server ── User (Europe)
│
└── CDN Edge Server ── User (USA)
The main server is called the origin server.
The distributed servers are commonly called edge servers or Points of Presence (PoPs).
Why Do We Need a CDN?
Without a CDN, users from different parts of the world may have to communicate with the same origin server.
For example:
User in India ───────┐
User in Germany ─────┤
User in USA ─────────┼──→ Origin Server
User in Japan ───────┘
As traffic grows, this creates several problems:
- Higher latency
- More traffic reaching the origin
- Increased server load
- Slower image and video delivery
- Poor performance for users far away from the server
A CDN solves this by distributing frequently requested content geographically.
How Does a CDN Work?
Suppose your website contains an image:
/images/product.jpg
A user in India requests it.
Instead of immediately contacting your origin server, the request goes through the CDN:
User
↓
CDN
↓
Nearest Edge Server
↓
Cache?
The CDN checks whether the requested content is already available in its cache.
There are two important possibilities:
- Cache HIT
- Cache MISS
Let's understand both.
1. Cache HIT
A cache hit happens when the edge server already has the requested content.
User
↓
CDN Edge Server
↓
Cached Content
↓
User
The CDN can immediately return the content.
The origin server doesn't need to process the request.
This is called a cache hit.
The closer the cached content is to the user, the faster the response can be.
2. Cache MISS
What happens if the edge server doesn't have the requested content?
That's a cache miss.
The CDN needs to fetch the content from the origin server.
User
↓
CDN Edge Server
↓
Origin Server
↓
Content
↓
CDN Cache
↓
User
The CDN requests the content from the origin.
It then stores a copy in its cache.
When future users request the same resource, the CDN can serve it directly from the edge instead of contacting the origin again.
A Simple Example
Suppose your website has 1 million users requesting the same image.
Without a CDN:
1,000,000 Requests
↓
Origin Server
The origin server has to handle all those requests.
With a CDN:
┌── Edge Server
│
1M Users ───────────┼── Edge Server
│
└── Edge Server
↓
Origin Server
The CDN can serve most requests from its cache.
Instead of the origin handling every request individually, it primarily needs to provide the content when an edge cache doesn't already have it.
This is one of the key ways CDNs help systems scale.
What Does a CDN Cache?
CDNs are commonly used for static content, such as:
- Images
- CSS files
- JavaScript files
- Fonts
- Videos
- PDFs
- Static HTML
- Downloadable files
For example:
logo.png
styles.css
app.js
font.woff2
product-image.webp
These resources are excellent candidates for caching because they usually don't need to be generated from scratch for every user.
Where Is the Content Stored?
CDNs have geographically distributed locations called Points of Presence (PoPs).
A simplified CDN network might look like this:
CDN Network
┌── USA PoP
│
Origin ────┼── Europe PoP
│
├── India PoP
│
└── Singapore PoP
When a user makes a request, the CDN attempts to route them to an appropriate edge location.
This reduces the physical distance that data needs to travel.
CDN Request Flow
A simplified CDN request flow looks like this:
User
│
▼
DNS / CDN Routing
│
▼
Nearest Edge
│
┌─────┴─────┐
│ │
Cache HIT Cache MISS
│ │
▼ ▼
User Origin
│
▼
CDN
│
▼
User
The important idea is:
If the content is already cached at the edge, the origin doesn't need to be involved.
How Does the CDN Know Which Server to Use?
CDNs typically use DNS, routing, and network-level techniques to direct users toward an appropriate edge location.
For example:
User in India
↓
CDN
↓
India / Nearby Edge Server
While:
User in Germany
↓
CDN
↓
European Edge Server
The goal is to serve content from a location that provides a fast and reliable connection.
What Is Cache-Control?
Caching isn't useful if the CDN doesn't know how long content should remain cached.
HTTP provides headers such as:
Cache-Control: public, max-age=86400
This tells caches that the response can be stored and reused for the specified period.
For static assets, developers often use long cache durations.
For example:
app.abc123.js
Because the filename contains a version/hash, it can safely be cached for a long time.
When the file changes, the application can generate a new filename:
app.abc123.js
↓
app.xyz789.js
The new filename represents a new version of the asset.
What Happens When Content Changes?
This is one of the biggest challenges with CDNs.
Suppose the CDN has:
logo.png → Old Version
You update the file on your origin server.
However, the CDN may still have the old version cached.
This is called stale content.
There are several ways to handle it.
1. Shorter Cache TTL
Set a shorter expiration time so cached content is refreshed more frequently.
2. Cache Invalidation
Explicitly tell the CDN to remove cached content.
For example:
Invalidate:
/images/logo.png
3. Cache Busting
Change the filename or URL whenever the content changes.
logo-v1.png
logo-v2.png
Or:
app.abc123.js
app.xyz789.js
For modern web applications, versioned assets are often the preferred approach.
CDN vs Origin Server
It's important to understand that a CDN doesn't necessarily replace your backend.
Instead, they work together:
CDN
│
▼
Origin Server(s)
│
▼
Database
The CDN handles content that can be cached and delivered efficiently.
The origin continues handling things such as:
- Authentication
- Business logic
- Database operations
- Personalized responses
- Dynamic API requests
Can a CDN Cache API Responses?
Yes — but it depends on the API.
Consider:
GET /products
If the response is the same for many users, caching it can be useful.
But consider:
GET /my-profile
This response is user-specific.
You don't want one user's private data to accidentally become another user's cached response.
For example:
User A → CDN Cache
↓
User A Data
↓
User B → ❌
Therefore, CDN caching requires careful consideration of:
- Cache-Control
- Authorization
- Cookies
- User-specific data
- Cache keys
Caching dynamic responses can be powerful, but incorrect caching can create serious security and correctness problems.
CDN and Dynamic Content
Modern CDNs can do much more than simply serve static files.
Many CDN platforms can provide capabilities such as:
- Edge functions
- Request routing
- Compression
- Image optimization
- TLS termination
- DDoS protection
- Web Application Firewall (WAF)
- API acceleration
This makes the CDN an important component of modern distributed architectures.
CDN in a Real-World Architecture
A typical production architecture might look like this:
Users
│
▼
CDN
│
┌───────┴────────┐
│ │
Static Content Dynamic Requests
│ │
▼ ▼
CDN Cache Load Balancer
│
┌────────┼────────┐
▼ ▼ ▼
Server 1 Server 2 Server 3
│ │ │
└────────┼────────┘
▼
Database
Each component has a specific responsibility.
CDN
Handles globally distributed and cacheable content.
Load Balancer
Distributes dynamic requests across application servers.
Application Servers
Handle business logic and dynamic operations.
Database
Stores persistent application data.
This separation allows each layer to scale independently.
CDN + Load Balancer
CDNs and load balancers are sometimes confused because both distribute traffic.
But they solve different problems.
CDN
A CDN focuses on:
- Caching
- Global content delivery
- Reducing latency
- Offloading the origin
Load Balancer
A load balancer focuses on:
- Distributing requests across servers
- Health checks
- Failover
- Server capacity
- Scaling application infrastructure
They often work together:
Users
↓
CDN
↓
Load Balancer
↓
Application Servers
↓
Database
Think of it this way:
CDN distributes content geographically.
Load balancer distributes application traffic across servers.
Benefits of Using a CDN
1. Lower Latency
Content can be served from a location closer to the user.
2. Reduced Origin Load
Cached content doesn't need to be fetched from the origin repeatedly.
3. Better Scalability
The CDN can absorb a large portion of traffic.
4. Better Global Performance
Users across different geographic regions can receive content from nearby edge locations.
5. Higher Availability
CDNs can provide additional resilience when origin infrastructure experiences problems.
6. Improved Security
Many CDN providers offer security features such as DDoS protection and WAF capabilities.
What Are the Trade-offs?
CDNs aren't magic.
They also introduce additional complexity.
Some challenges include:
- Cache invalidation
- Stale content
- Configuration complexity
- Additional cost
- Debugging cached responses
- Incorrect caching of private data
- Cache consistency issues
There's a famous saying:
"There are only two hard things in Computer Science: cache invalidation and naming things."
Caching is incredibly powerful, but it needs to be designed carefully.
The Big Picture
A CDN is essentially a distributed caching layer between users and your origin infrastructure.
Instead of:
Users → Origin
we get:
Users
↓
CDN Edge
↓
Cache
↓
Origin
When the requested content is already cached, the origin doesn't need to be involved.
That simple idea becomes incredibly powerful at global scale.
Key Takeaway
A CDN isn't just a tool for making websites "faster."
It's a fundamental building block for scalable global systems.
By moving frequently requested content closer to users, CDNs can:
- Reduce latency
- Reduce origin traffic
- Improve scalability
- Improve availability
- Handle massive traffic spikes
- Deliver content globally
The next time a website loads an image, video, JavaScript file, or stylesheet almost instantly, there's a good chance a CDN is working behind the scenes.
In system design, the closer you can bring data to the user, the less work your origin infrastructure has to do.
![Kubernetes Networking [Level-8: kube-proxy / iptables / IPVS / eBPF]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fbnznebghw6b2b6djr3e5.png)
