What Is a CDN?

A Content Delivery Network (CDN) is a geographically distributed network of servers that delivers content from locations closer to users. Instead of every request traveling to the application's origin server, a CDN can serve cached content from an edge location near the requester.

CDNs reduce latency, decrease origin traffic, improve scalability, and can help absorb traffic spikes. They are commonly used for images, JavaScript, CSS, downloads, video, and other static content, but modern CDNs can also cache API responses and perform routing, security, and computation at the edge.

Table of Contents

• Why Use a CDN?
• How a CDN Works
• Edge Locations and the Origin
• CDN Caching
  • Cache Hit
  • Cache Miss
  • Cache Key
• TTL and Cache-Control
• Cache Invalidation
• Dynamic Content and APIs
• CDN vs Reverse Proxy vs Application Cache
• CDN Failure Scenarios
• Production Design Example
• Common CDN Mistakes
• Production Checklist
• Frequently Asked Questions
  • Is a CDN the Same as Web Hosting?
  • Is a CDN Only for Static Files?
  • Does a CDN Reduce Database Load?
  • Is a CDN a Load Balancer?
  • When Should a CDN Be Used?
• Conclusion
  • More Articles to Read

Why Use a CDN?

Without a CDN, users normally retrieve content from the application's origin infrastructure.

User in Europe
      |
      |
      | long network path
      |
      v
Origin in US

The farther the user is from the origin, the more network latency can affect response time. Every request also consumes origin bandwidth and compute capacity.

A CDN introduces geographically distributed edge locations:

                 Origin
                   |
          +--------+--------+
          |        |        |
          v        v        v
      US Edge  EU Edge  Asia Edge
          |        |        |
          v        v        v
        Users    Users    Users

When content is cached at the edge, the user can retrieve it without contacting the origin.

This provides several benefits:

• lower latency for geographically distributed users;
• less traffic reaching the origin;
• reduced origin bandwidth consumption;
• better handling of traffic spikes;
• faster delivery of large static assets;
• additional resilience when cached content can survive temporary origin problems.

A CDN is therefore both a performance optimization and an architectural layer that can reduce pressure on backend infrastructure.

How a CDN Works

Consider a user requesting an image:

GET /images/product-481.webp

DNS and CDN routing direct the request toward an appropriate edge location.

User
  |
  v
DNS
  |
  v
CDN Edge
  |
  +-- cached? -- YES --> Response
  |
  NO
  |
  v
Origin
  |
  v
CDN caches response
  |
  v
User

The first request at an edge may need to reach the origin. Later requests for the same cacheable resource can be served directly from the CDN.

Suppose a 2 MB image is requested one million times.

Without edge caching:

1,000,000 requests
       |
       v
     Origin

With a CDN, the origin may serve only the requests required to populate or refresh edge caches, while the majority of requests are handled by the CDN.

This changes the origin from being the direct serving point for every request into the authoritative source from which edge copies are populated.

Edge Locations and the Origin

The origin is the authoritative backend from which the CDN retrieves content when it cannot satisfy a request itself.

An origin can be:

• a web server;
• an object-storage bucket;
• a load balancer;
• an API service;
• another reverse proxy;
• multiple origins selected by path or routing rules.

An edge location is CDN infrastructure positioned closer to users.

                    Origin
                      |
        +-------------+-------------+
        |             |             |
        v             v             v
     Edge A        Edge B        Edge C
    New York       London        Tokyo
        |             |             |
      Users         Users         Users

The exact physical architecture differs between CDN providers, but the core idea is the same: move reusable content closer to consumers and avoid unnecessary trips to the origin.

CDNs also depend heavily on DNS and network routing. For a broader view of how these components fit together, see DNS, Load Balancers, and Reverse Proxies.

CDN Caching

Caching is one of the most important CDN capabilities. Whether a request reaches the origin depends on whether the edge has a usable cached response for the request's cache key.

Cache Hit

A cache hit means the edge already has a valid cached response.

User
  |
  v
CDN Edge
  |
  | HIT
  v
Cached Response

The origin receives no request.

For high-volume static assets, a high CDN hit ratio can remove enormous amounts of traffic from the origin.

Cache Miss

A cache miss means the CDN cannot use a cached response.

User
  |
  v
CDN Edge
  |
  | MISS
  v
Origin
  |
  v
Response
  |
  +----> Cache at edge
  |
  v
User

Misses happen when a resource has not yet been cached, has expired, has been invalidated, or the request produces a different cache key.

A miss is not necessarily a problem. The goal is to cache resources where reuse provides meaningful value.

Cache Key

The CDN needs a way to decide whether two requests can share the same cached response. This is determined by the cache key.

A simple cache key may contain only the path:

/images/logo.png

More complex configurations can include query parameters, headers, cookies, or other request properties.

Path
+ Query String
+ Selected Headers
= Cache Key

Cache-key design has a major effect on cache efficiency.

Suppose these requests return identical content:

/products?id=481&tracking=a
/products?id=481&tracking=b
/products?id=481&tracking=c

If the tracking parameter is included in the cache key, the CDN may store three copies and produce unnecessary origin requests.

On the other hand, excluding a parameter that actually changes the response can cause the wrong content to be served.

The cache key should therefore contain everything that changes the representation and exclude request attributes that do not.

TTL and Cache-Control

Cached content cannot remain valid forever when the underlying resource can change. CDNs therefore use expiration rules to determine how long a response remains reusable.

HTTP caching headers can communicate this policy:

Cache-Control: public, max-age=3600

This indicates that the response can be cached and reused for a defined period.

Different content can use very different lifetimes.

Versioned asset names are especially useful:

/assets/app.a82f3c.js
/assets/app.b1947e.js

When the content changes, the URL changes. The old file can safely remain cached for a long time because new pages reference the new URL.

This is usually more efficient than repeatedly invalidating stable URLs.

Cache Invalidation

Sometimes cached content must be replaced before its TTL expires.

Suppose:

/products/481

CDN:    price = $99
Origin: price = $79

If the cached representation must change immediately, the system can invalidate or purge it from the CDN.

Application Update
       |
       v
Origin Updated
       |
       v
CDN Invalidation
       |
       v
Next request → MISS
       |
       v
Fetch new version

Invalidation is useful, but excessive invalidation reduces the benefit of caching and can produce bursts of origin traffic.

For static assets, immutable versioned URLs are often preferable:

Old:
/logo.v17.png

New:
/logo.v18.png

The new URL naturally creates a new cache entry without requiring every edge to delete the old one immediately.

For broader cache invalidation strategies and their trade-offs, see What Is Cache Invalidation?.

Dynamic Content and APIs

CDNs are strongly associated with static files, but some dynamic responses can also be cached.

Consider a public API:

GET /api/popular-products

If the response is identical for all users and can be several seconds old, the CDN can cache it:

10,000 users
     |
     v
CDN
     |
     | one refresh periodically
     v
API Origin
     |
     v
Database

This can reduce load not only on application servers but also on databases and downstream services.

Dynamic caching becomes dangerous when responses depend on identity or request-specific state.

For example:

GET /api/account

Authorization: Bearer ...

Incorrect shared caching could expose one user's response to another user.

Cache policy therefore needs to distinguish carefully between:

• public shared content;
• personalized content;
• authenticated responses;
• responses affected by cookies;
• responses affected by headers or query parameters.

Do not cache dynamic responses at the CDN merely because they use HTTP GET. Cacheability depends on response semantics.

CDN vs Reverse Proxy vs Application Cache

A CDN is one of several places where caching can happen.

User
  |
  v
CDN
  |
  v
Reverse Proxy
  |
  v
Application
  |
  v
Distributed Cache
  |
  v
Database

Each layer serves a different purpose.

The layers can complement each other rather than compete.

For example, an image may be served entirely from the CDN, while a product API response misses the CDN but hits an application cache, avoiding a database query.

CDN vs Reverse Proxy vs Application Cache provides a deeper comparison of these layers.

CDN Failure Scenarios

A CDN reduces origin traffic during normal operation, but production architecture also needs to account for failures and unusual traffic patterns.

Edge cache miss spike. A large number of simultaneous misses can suddenly increase origin traffic.

Normal:
Users → CDN → mostly HIT

After mass expiration:
Users → CDN → many MISS → Origin

This resembles a cache stampede at the edge. Long-lived versioned assets, staggered expiration, request collapsing, and appropriate caching policies can reduce the risk.

Origin unavailable. Some CDNs can continue serving cached objects while the origin is unavailable, depending on configuration and freshness rules.

CDN unavailable. If traffic bypasses the CDN and reaches the origin directly, the origin may receive far more traffic than it normally handles.

Bad cache configuration. Accidentally caching personalized content can become a security incident rather than merely a performance problem.

Invalidation storm. Purging a large portion of the cache can cause many edge locations to request the same content from the origin again.

The origin should therefore be protected even when a CDN normally absorbs most public traffic.

Production Design Example

Consider an international e-commerce application serving product pages, images, JavaScript, CSS, and public catalog APIs.

                     Users
                       |
                       v
                      DNS
                       |
                       v
                      CDN
                  /     |     \
                 /      |      \
          Static HIT  API HIT   MISS
              |          |        |
              v          v        v
           Response   Response   Origin
                                  |
                                  v
                            Load Balancer
                                  |
                            +-----+-----+
                            |           |
                            v           v
                          API-1       API-2
                              \       /
                               \     /
                                Cache
                                  |
                                  v
                               Database

Static assets use versioned filenames:

/assets/app.79b4f1.js
/assets/styles.a192c8.css
/images/products/481.4.webp

These resources can use long cache lifetimes because a deployment generates new URLs when the content changes.

A public product endpoint can use a shorter CDN TTL:

GET /api/products/481

Cache-Control: public, max-age=30

If the product receives 5,000 requests per second globally, edge caching can prevent most of those requests from reaching the application.

Authenticated endpoints are excluded from shared caching:

/api/products/481     → cacheable
/api/categories       → cacheable
/api/account           → bypass
/api/orders            → bypass
/api/payment-methods   → bypass

The architecture also separates cache keys from irrelevant tracking parameters.

For example:

/product/481?utm_source=email
/product/481?utm_source=search
/product/481?utm_source=social

If tracking parameters do not affect page content, they should not create separate CDN cache objects.

When a product image changes, the system creates a new versioned path instead of purging the old image globally:

Before:
/images/products/481.v3.webp

After:
/images/products/481.v4.webp

The old object can expire naturally.

For public API data that must change quickly, targeted invalidation can be used:

Product updated
      |
      v
Database commit
      |
      v
Invalidate:
/api/products/481
      |
      v
Next request repopulates CDN

The application also monitors CDN behavior rather than treating it as invisible infrastructure.

The important metric is not simply CDN traffic. A useful CDN configuration should measurably reduce latency or origin work without introducing unacceptable staleness or security risk.

Common CDN Mistakes

• Caching authenticated responses without understanding the cache key. This can expose private data between users.
• Including unnecessary query parameters in cache keys. Cache fragmentation reduces the hit ratio.
• Ignoring parameters that change the response. Different requests can incorrectly receive the same cached object.
• Using very short TTLs for immutable assets. The origin receives unnecessary refresh traffic.
• Using stable filenames for versioned static assets. Deployments require more invalidation and create stale-content problems.
• Purging the entire CDN for small changes. Large invalidations can create an origin traffic spike.
• Assuming every GET request is safe to cache. GET responses can still be personalized or authorization-dependent.
• Ignoring compression. Large responses waste edge bandwidth and increase transfer time.
• Ignoring cache hit ratio. A CDN that forwards almost every request may provide little caching benefit.
• Leaving the origin publicly unrestricted. Attackers may bypass CDN protections and send traffic directly to the backend.
• Designing the origin only for normal CDN miss traffic. Cache loss or invalidation can create much larger bursts.
• Treating the CDN as a replacement for backend caching. Edge caching and application caching solve different problems.

Production Checklist

• Identify which resources are safe to cache publicly.
• Define the origin for each content type.
• Use long TTLs for immutable versioned assets.
• Use content-hashed or versioned filenames for static assets.
• Define shorter TTLs for frequently changing public content.
• Exclude private and user-specific responses from shared caching unless explicitly designed otherwise.
• Design cache keys carefully.
• Exclude irrelevant tracking parameters from cache keys.
• Include request attributes that genuinely change the response.
• Configure HTTP caching headers deliberately.
• Use targeted invalidation instead of global purges where possible.
• Protect the origin from direct unwanted traffic.
• Use TLS between users and the CDN.
• Use secure communication between the CDN and origin.
• Enable appropriate response compression.
• Define behavior when the origin is unavailable.
• Define behavior when cached content becomes stale.
• Plan for traffic spikes after cache expiration or invalidation.
• Monitor cache hit ratio.
• Monitor origin request rate.
• Monitor edge and origin latency.
• Monitor CDN and origin error rates.
• Monitor bandwidth offload.
• Test cache behavior during deployments.
• Test invalidation behavior.
• Test personalized endpoints for accidental caching.
• Test origin failure.
• Test large cache-miss bursts.

Frequently Asked Questions

A CDN is best understood as a geographically distributed delivery layer. Caching is one of its central capabilities, but routing, TLS termination, traffic protection, and edge processing can also be part of modern CDN architectures.

Is a CDN the Same as Web Hosting?

No. The origin normally stores or generates the authoritative content, while the CDN distributes and optionally caches that content closer to users.

Some modern platforms blur this distinction by providing storage and edge computation together, but the architectural roles remain useful to distinguish.

Is a CDN Only for Static Files?

No. Static files are the simplest and most common CDN workload, but public HTML pages and API responses can also be cached when their semantics allow it.

Dynamic caching requires more careful cache-key, freshness, authorization, and invalidation design.

Does a CDN Reduce Database Load?

It can. If the CDN caches a response that would otherwise require application processing and database queries, each cache hit avoids that backend work.

Caching images and JavaScript reduces origin bandwidth but may have little direct effect on database traffic. The benefit depends on what is cached.

Is a CDN a Load Balancer?

Not exactly. A CDN routes users toward geographically distributed edge infrastructure and can reduce origin traffic through caching. A load balancer typically distributes requests across backend instances or services.

Both can participate in traffic routing, but they operate at different layers and solve different architectural problems. Load Balancing Explained: Distributing Traffic at Scale covers backend load balancing separately.

When Should a CDN Be Used?

A CDN is particularly valuable when an application serves users across multiple geographic regions, delivers significant static content, experiences large traffic volumes, or has reusable public responses that can be served from the edge.

For a small application serving users close to one origin with little cacheable content, the performance improvement may be modest. The decision should be based on latency, traffic, bandwidth, reliability, and security requirements rather than adding a CDN automatically.

Conclusion

A CDN places geographically distributed infrastructure between users and an application's origin. By serving reusable content from nearby edge locations, it can reduce latency, decrease origin traffic, lower bandwidth requirements, and improve scalability during traffic spikes.

Effective CDN design depends on more than enabling caching. Cache keys, TTLs, HTTP headers, invalidation, personalized content, origin protection, failure behavior, and observability all determine whether edge caching is safe and useful.

Key Takeaway: use a CDN to move reusable content closer to users and keep unnecessary requests away from the origin. Cache immutable assets aggressively, design dynamic caching carefully, and treat cache misses and CDN failures as production scenarios the origin must be prepared to handle.

More Articles to Read

• Content Delivery Network (CDN): Overview and Use Cases
• Networking Best Practices for Production Systems
• Caching Best Practices for Distributed Applications