CDNs Explained: How the Internet Brings Content Closer to You

Ayantik Sarkar

9 min read

·

Sep 26, 2026

--

Listen

Share

Press enter or click to view image in full size

Imagine you have built a website.

Your backend server is running in the US, but your users are spread across India, Europe, Asia and other parts of the world.

A user from India opens your website.

Their request has to travel all the way to your server in the US. Your server processes the request and sends the response back to India.

It works.

But there is one obvious problem.

The server is far away.

And distance matters on the internet.

You can have a very powerful server, but you cannot remove the physical distance between your server and your users.

This is one of the problems that a CDN helps solve.

What is a CDN?

CDN stands for Content Delivery Network.

In simple words, a CDN is a network of servers placed in different parts of the world.

Instead of making every user communicate directly with your main server, the CDN can handle many requests from servers that are much closer to the users.

For example:

                Your Server
                    USA
                     |
          -----------------------
          |          |          |
        India      Europe      Japan
         CDN         CDN        CDN
          |           |          |
        Users       Users      Users

Your main server is usually called the origin server.

The CDN sits between your users and this origin server.

The important idea is:

Put commonly requested content closer to the people who need it.

But where exactly does the CDN put these servers?

That brings us to Points of Presence.

What is a Point of Presence?

You will often hear the term PoP when reading about CDNs.

PoP stands for Point of Presence.

Do not let the name make it sound complicated.

A PoP is basically a physical location where a CDN has its infrastructure.

For example, a CDN might have PoPs in:

India
  |
  +-- Mumbai
  +-- Delhi
  +-- Bengaluru
  +-- Chennai

Europe
  |
  +-- London
  +-- Frankfurt
  +-- Amsterdam

These locations contain the equipment needed by the CDN to receive requests, serve cached content and sometimes run code.

You can think of a PoP as a local branch of the CDN.

Your origin server is like your main warehouse.

A PoP is like a smaller warehouse closer to the customer.

PoP and edge server are not exactly the same thing

These terms are often used together, so it is worth understanding the difference.

A PoP is the location.

An edge server is the server doing the actual work closer to the user.

You can roughly imagine:

PoP
 |
 +-- Edge Server
 +-- Edge Server
 +-- Network equipment
 +-- Other infrastructure

Different CDN providers may use these terms slightly differently, but this is a useful mental model.

Why does a CDN reduce latency?

Let’s say your server is in the US and a user is in India.

Without a CDN:

User in India
      |
      |-------------------->
      |                     |
      |                  Server
      |                   USA
      |                     |
      <--------------------|

The request has to travel a long distance.

Now suppose your CDN has a PoP in India.

User in India
      |
      v
Indian CDN PoP
      |
      v
   Content

If the requested content is already available there, the user does not need to contact your server in the US.

The response comes from a much closer location.

That is the basic reason a CDN can reduce latency.

Latency simply means the time taken for data to travel between two points.

But how does the CDN know which PoP to use?

A CDN can have hundreds or thousands of locations.

When a user makes a request, the CDN has to decide which location should handle it.

It uses different networking techniques to make this decision.

You do not need to know all of them to understand the basic idea.

The CDN tries to send the request to an appropriate location based on things such as:

Where is the user?
How is the network between the user and the PoP?
Is that PoP healthy?
Does it have enough capacity?

And one important thing to remember is that the physically closest PoP is not always the best one.

A location 100 km away can sometimes have a worse network path than a location 200 km away.

So the CDN cares about the network path, not just geographical distance.

Now comes the most important part: caching

This is where CDNs become really useful.

Suppose your website has this image:

/images/banner.jpg

A user from India requests it.

The request reaches a CDN PoP.

The CDN asks:

“Do I already have this image?”

If the answer is no, it is called a cache miss.

The CDN gets the image from your origin server.

User
 |
 v
CDN PoP
 |
 | Cache miss
 v
Origin Server
 |
 v
CDN PoP
 |
 v
User

The CDN can now store a copy of the image.

Suppose another user requests the same image.

This time the CDN already has it.

That is called a cache hit.

User
 |
 v
CDN PoP
 |
 | Cache hit
 v
Image

The origin server does not need to send the image again.

This is the basic idea behind CDN caching.

Why is caching so useful?

Imagine 1 million users request the same image.

Without caching:

1,000,000 requests
        |
        v
Origin Server

Your origin has to deal with all of them.

With CDN caching:

First request
      |
      v
Origin Server
      |
      v
CDN stores image

Next 999,999 requests
      |
      v
     CDN

The origin may only need to provide the content when the CDN does not already have a usable copy.

This reduces the work your backend has to do.

It can also reduce latency for users because the content can be served from a nearby location.

What kind of content can a CDN cache?

Some content is very easy to cache.

For example:

logo.png
style.css
app.js
product-image.jpg
video.mp4
font.woff2

These files are often the same for many users.

But consider:

/my-account

This page might be different for every user.

For example:

Ayantik -> Balance: Rs 10,000

Rahul -> Balance: Rs 2,000

You obviously do not want the CDN to give Rahul Ayantik’s page.

So not everything should be cached.

This is one of the important things developers have to think about when using a CDN.

How long does the CDN keep something?

Suppose the CDN stores:

app.js

What happens when you release a new version of app.js?

The CDN might still have the old version.

This is where something called TTL comes in.

TTL means Time To Live.

It basically tells the cache how long a piece of content can be considered fresh.

For example:

Keep this file for 1 hour.

After that, the CDN may need to check whether there is a newer version.

This creates a simple tradeoff.

Longer caching:

Less work for origin
Faster responses
But old content may stay longer

Shorter caching:

More requests to origin
Content becomes fresh sooner

And this leads to one of the classic problems in software engineering:

Cache invalidation.

Cache invalidation

Suppose your CDN has copies of an image in:

India
USA
Europe
Japan
Singapore

You replace the image on your origin server.

Now some CDN locations may still have the old image.

You need a way to tell them:

“The old version is no longer valid.”

This can be done using things such as cache purging, expiration times or versioned file names.

For example, instead of:

app.js

you might have:

app.123abc.js

When you release a new version:

app.456xyz.js

The URL changes, so the CDN knows that this is a different file.

CDN vs edge computing

So far, we have mainly talked about storing content at the edge.

But what if we could also run some code there?

That is where edge computing comes in.

The idea is simple:

CDN caching:

Bring data closer to the user.

Edge computing:

Bring some computation closer to the user.

For example, imagine a request comes from India.

The edge could inspect the request and decide:

User is from India
       |
       v
Send Indian version

Instead of sending the request all the way to your main server just to make that decision, the decision can sometimes be made at the CDN location itself.

Edge computing can be useful for things such as:

Redirects
Authentication checks
Request routing
Rate limiting
Personalization
A/B testing
Simple request processing

A/B testing means showing different versions of something to different groups of users so you can compare how they behave.

Then why not run the entire backend at the edge?

This is where things get interesting.

If running code near the user is faster, why not put the entire backend in every CDN location?

Because your backend usually depends on something very important:

Your data.

Suppose your application is running at an Indian CDN location, but your database is in Singapore.

You now have:

User
 |
 v
India Edge
 |
 v
Singapore Database

The computation is close to the user.

But the database is still far away.

So if every request needs to talk to the database, you have not completely removed the latency problem.

Databases also make things harder

Imagine you have users in India, Europe and the USA.

Now suppose every location has its own copy of your database.

You have to keep these copies synchronized.

What happens if a user in India changes something at exactly the same time as another user changes the same thing in the USA?

Which update wins?

How quickly should the other locations see the change?

How do you handle transactions?

These are distributed systems problems.

A distributed system simply means that different parts of your application are running on different machines or in different locations and need to work together.

This can be extremely powerful.

But it also makes the system much more complicated.

Edge environments also have limits

Edge computing is generally useful for relatively small and fast pieces of work.

Depending on the platform, edge code can have limits on things such as:

CPU
Memory
Execution time
File access
Long-running processes

You would not normally run something like:

Train a large machine learning model
Process a huge file
Run a heavy database query

at every edge location.

Those workloads are better suited to infrastructure designed for heavy computation.

So what should actually go to a CDN?

A useful way to think about it is:

                  User
                   |
                   v
                CDN Edge
                   |
          -------------------
          |                 |
       Cached           Edge Logic
       Content          if needed
          |                 |
          -----------+-------
                     |
                     v
                  Backend
                     |
                     v
                  Database

The CDN handles things that can be handled close to the user.

Your backend handles the application logic that needs more resources or access to your data.

Your database stores the persistent data.

The CDN does not replace your backend.

It helps your backend by handling work that does not need to reach it.

Think of it like a warehouse

Imagine your company has one huge warehouse in the US.

Customers from India, Europe and Japan all need products.

If every customer has to travel to the US warehouse, things become slow.

So you create smaller warehouses closer to your customers.

Main Warehouse
                       |
        -------------------------------
        |              |              |
    India Store    Europe Store    Japan Store
        |              |              |
    Customers      Customers      Customers

The main warehouse is your origin server.

The smaller warehouses are like CDN PoPs.

The products stored in them are cached content.

The customers are your users.

And edge computing is like allowing the local warehouse to make certain simple decisions without calling the main warehouse every time.

That is basically what a CDN is doing.

The bigger picture

A modern application can look something like this:

Internet
                            |
              -----------------------------
              |            |              |
            User         User           User
              |            |              |
              v            v              v
           CDN PoP      CDN PoP        CDN PoP
              |            |              |
              |     Cache / Edge Code     |
              |            |              |
              ----------- Backend ---------
                           |
                           v
                        Database

The important thing is not that every request goes through the origin.

The important thing is that as much work as safely possible is handled closer to the user.

That could mean serving a cached image.

It could mean returning a cached JavaScript file.

It could mean running a small piece of code at the edge.

Or it could mean routing the request to the appropriate backend.

But when the request needs your actual application state or database, it can still go to the origin.

The simple mental model

If you remember only a few things, remember these:

Origin server

Your main application infrastructure.

PoP

A physical location where the CDN has infrastructure.

Edge server

A server working close to the user, usually within or associated with a CDN location.

CDN caching

Keeping frequently requested content at the edge.

Cache hit

The CDN already has the content.

Cache miss

The CDN needs to get the content from the origin.

Edge computing

Running some code close to the user instead of sending every request to the origin.

And the whole idea can be summarized in one sentence:

Do not make every user travel all the way to your main server when the required work can be done closer to them.

That is the basic idea behind CDNs.