Content Delivery Networks: Moving Reusable Content Closer to Users

A user in Chennai should not need every image byte to cross an ocean from an origin server for every page view.

A content delivery network, or CDN, places reusable responses at distributed edge locations.

A CDN serves suitable content from infrastructure closer to users, reducing delay, network distance, and load on the origin.

The origin remains the authoritative source. The CDN operates a geographically distributed cache and request-routing layer in front of it.

A concrete example: a product image

The first visitor near Chennai requests:

https://example.com/images/shoe-a7.webp

The nearby CDN edge does not have the image, so it fetches it from the origin, returns it, and stores a copy.

Later nearby visitors receive the cached copy from that edge.

Other edge locations fill independently as users request the image. This pull model avoids preloading every object everywhere.

Edge, point of presence, and origin

A CDN operates points of presence in many network locations. Each location may contain edge servers that receive user traffic.

The origin may be:

• A web server
• Object storage
• A load balancer
• An application platform
• Another CDN layer

DNS or anycast routing guides clients to an appropriate edge based on network topology, health, and policy.

"Nearest" often means network-close rather than shortest geographic distance.

Cacheability comes from HTTP semantics

HTTP response headers tell caches how to handle content.

Examples:

Cache-Control: public, max-age=3600

This allows shared caching for one hour.

Cache-Control: private, no-store

This prevents shared storage of personalized sensitive content.

CDNs may support additional edge-specific TTL rules, but origin headers should express the application's intended caching semantics clearly.

Incorrect caching can expose one user's content to another.

Cache keys decide which requests share a response

A CDN cache key often includes:

• Host
• Path
• Selected query parameters
• Selected headers
• Content encoding

If every tracking parameter creates a different key, reuse falls sharply.

If a response varies by language but the key ignores language, users may receive the wrong version.

Cookies and authorization headers frequently make a response user-specific. They should be excluded, forwarded selectively, or bypass caching according to the application's design.

Versioned URLs simplify freshness

Static assets can use content-based names:

/assets/app.9f31c2.js

When content changes, the URL changes. The old file can be cached for a long time because it never needs to become the new file.

HTML references the latest version.

This technique avoids urgent global invalidation and allows:

Cache-Control: public, max-age=31536000, immutable

Versioning is safer than replacing content behind a long-cached URL.

Validation avoids unnecessary transfer

When a cached item expires, the edge can ask whether it changed.

The origin may supply:

• ETag
• Last-Modified

The edge sends a conditional request. If unchanged, the origin returns 304 Not Modified without the full body.

Validation still requires an origin round trip, but saves bandwidth and object transfer.

Stale-while-revalidate policies can serve an old copy briefly while refreshing in the background.

Purging removes cached content

Sometimes content must disappear before TTL expiration, such as:

• Incorrect pricing
• Sensitive accidental publication
• Legal removal
• Emergency application rollback

CDNs provide purge or invalidation APIs.

Global purges take time to propagate and may cost money or have rate limits. A purge also sends subsequent traffic back to the origin until caches refill.

Use versioned assets for normal releases and reserve purges for genuinely mutable or urgent content.

CDNs can accelerate dynamic traffic

Not every request can be cached. CDNs may still improve dynamic requests through:

• Optimized network routes
• Connection reuse
• TLS termination near users
• Modern transport protocols
• Compression
• Request coalescing
• Persistent connections from edge to origin

The edge shortens the user's network path and maintains efficient long-distance connections.

Application processing and database latency remain. A CDN cannot cache or route away every backend bottleneck.

TLS at the edge

Users usually establish HTTPS with the CDN edge.

The CDN manages certificates for the domain and may encrypt traffic from edge to origin as a second connection.

Security requires:

• Valid certificates
• Modern protocol settings
• Protected origin connections
• Correct host validation
• Restricted origin access

If attackers can bypass the CDN and call the origin directly, edge security controls may not protect it.

Origins can accept traffic only from trusted CDN identities or network ranges where supported.

DDoS and web security

CDNs operate large distributed networks and can absorb or filter some attacks before traffic reaches the origin.

Features may include:

• Volumetric attack mitigation
• Web application firewalls
• Bot controls
• Rate limiting
• Request-size limits
• Geographic rules

These controls reduce risk but require tuning. Aggressive rules can block legitimate users; permissive rules may pass harmful traffic.

Application authentication, validation, and secure code remain necessary.

Origin protection

A successful CDN can hide how much traffic the origin would receive without caching.

Protect the origin with:

• Capacity for expected misses
• Request collapsing
• Shield or mid-tier caches
• Rate limits
• Controlled failover
• Monitoring of cache hit ratio
• Restricted direct access

A cold cache after a configuration change can create a large origin surge.

The origin must survive realistic miss and purge scenarios, not only steady warm-cache traffic.

Personalized and private content

CDNs can deliver private files using signed URLs, signed cookies, or edge authorization.

The cache may store one encrypted or protected object while requiring each requester to prove access.

Careful design must prevent:

• Tokens appearing in cache keys unnecessarily
• Private responses becoming public
• Long-lived shared URLs
• Logs exposing credentials
• Access continuing after revocation longer than allowed

Caching policy and authorization policy must be designed together.

Global consistency is not instant

Edge locations fill and expire independently. Configuration and purges propagate across a distributed network.

For a short period:

• Some users may receive the old object.
• Some edges may have the new configuration.
• Others may fetch from origin.

Applications needing immediate global consistency should avoid depending on ordinary edge caching for that data.

CDNs optimize distribution; they do not turn the world into one instantaneous cache.

Measuring CDN performance

Track:

• Cache hit ratio by content type
• Edge and origin latency
• Origin request volume
• Error rates
• Bytes served
• Geographic performance
• Purge activity
• Security-rule matches
• Cost

Segment results. A high hit ratio for images can hide poor HTML or API caching.

Measure real-user performance because synthetic tests from one location cannot represent a global audience.

Knowledge check

1. What happens on the first cache miss at an edge?
2. Why is network proximity different from geographic proximity?
3. How do versioned asset URLs improve cache safety?
4. Why can a global purge overload the origin?
5. What protections are lost if users can bypass the CDN and reach the origin directly?

The one idea to remember

A CDN is a distributed edge cache and traffic layer. It moves reusable content and connections closer to users, but correct cache keys, HTTP policy, origin protection, and private-data handling determine whether that speed is safe.