What is a CDN?

What is a CDN?

A content delivery network, or CDN, is a distributed network of servers that helps deliver web content from locations closer to users. Instead of every visitor connecting to the origin application for every file, a CDN can serve cached content, terminate secure connections, apply routing logic, and enforce security policy at the edge.

The origin still remains the authoritative source for application logic and content. The CDN sits in front of it. When the CDN already has a valid copy of a response, it can reply directly. When it does not, it fetches from the origin, stores the response if policy allows, and returns it to the user. This pattern can improve performance, reduce origin load, lower bandwidth costs, and make sites more resilient during spikes.

The basic request flow

A typical CDN-backed request begins with DNS. The site hostname points users toward the CDN rather than directly to the origin. The CDN then routes the request to an edge location, often based on network topology, anycast routing, or load. At the edge, the CDN can check security rules, negotiate TLS, look for a matching cached object, and decide whether to contact the origin.

If the object is cacheable and fresh, the edge returns it as a cache hit. If not, the edge forwards the request to the origin or another cache layer. The origin responds with content and headers that help define how that content may be reused. The CDN may store the response according to those headers and local rules, then serve future matching requests without involving the origin.

This flow is not limited to images and scripts. CDNs can deliver HTML, APIs, media, downloads, and software packages. The right behavior depends on the route. A logo can be cached aggressively. A user account page should not be shared-cacheable. A product API might be cacheable for a short time if it does not contain user-specific data. Checkout and login endpoints usually need stricter handling.

What a CDN can improve

The most visible benefit is lower latency. Serving a cached file from a nearby edge avoids a long round trip to the origin. It also reduces TLS handshakes and origin fetches for repeated requests. Users far from the origin often see the largest improvement, but local users can also benefit when the origin is busy.

A CDN can also reduce origin workload. Public static assets, popular pages, and cacheable API responses no longer need to be generated for every request. During a traffic spike, this can be the difference between a stable site and an overloaded application stack. Additional cache layers, request collapsing, or origin shielding can reduce duplicate origin fetches when many edge locations miss at the same time.

Security is another major use case. A CDN can block obvious unwanted traffic before it reaches the origin, enforce TLS policy, absorb some volumetric pressure, rate-limit abusive patterns, apply WAF rules, and route requests through known control points. This does not replace application security, but it provides an important first layer for public-facing services.

What a CDN does not automatically fix

A CDN cannot make all dynamic work fast. If every request requires personalized database queries at a distant origin, the CDN may improve connection handling and filtering, but the application path still dominates. A CDN also cannot safely cache content when the response varies per user unless the cache key and privacy rules are correct.

It cannot fix direct origin exposure. If users or attackers can bypass the CDN and reach the origin IP directly, they may avoid security controls and overload infrastructure that was sized for CDN-proxied traffic. Operators should restrict origin access, validate host headers, and monitor for requests that do not come through the expected delivery path.

It also cannot make unclear ownership safe. CDN rules, application headers, DNS records, certificates, origin pools, and security policies often belong to different teams. If those teams do not coordinate, one change can undo another. A deployment that removes cache headers, a rule that ignores query strings, or an emergency purge that becomes routine can all create operational risk.

Design decisions that matter

The first decision is what should be cached. Public, versioned static assets are the easiest candidates. HTML and APIs require more care because they may vary by user, location, language, device, currency, authentication state, or experiment assignment. Each variation must either be part of the cache key, kept private, or not cached by shared infrastructure.

The second decision is freshness. Cache-Control headers, CDN TTL rules, purges, revalidation, and stale serving determine how long content can be reused and what happens when the origin is slow or unavailable. Long TTLs work well with versioned assets. Frequently changing pages may need shorter TTLs, targeted purges, or revalidation.

The third decision is routing and resilience. A CDN may use one origin, multiple origins, regional origins, health checks, or failover pools. Failover must be tested against real application behavior. A backup origin that lacks current data, credentials, certificates, or security rules can turn an outage into a data integrity or compliance problem.

Operations and troubleshooting

A CDN adds a layer that must be observable. Teams should be able to answer whether a request was served from cache, which edge handled it, which origin was contacted, how long the origin took, what status code was returned, and which security policies were applied. Without this evidence, incidents become arguments about whether the problem is DNS, the CDN, the origin, the application, or a third-party dependency.

Useful metrics include cache hit ratio, byte hit ratio, edge latency, origin latency, origin request rate, status codes, TLS errors, DNS changes, health check state, purge frequency, blocked requests, and rate-limit actions. Segment them by hostname, route, region, and cache status. Global averages can hide a broken route or a single region under pressure.

Changes should be controlled. Cache-key updates, TTL changes, WAF rules, bot controls, certificate updates, DNS changes, and origin-pool edits are production changes even when no application code is deployed. They need review, audit trails, rollback paths, and a shared understanding of which routes are sensitive.

Common CDN failure modes

The most serious failures involve privacy and origin protection. Private responses can leak when a shared cache does not vary correctly or when a route is mistakenly marked public. Origins can be attacked directly if access is not restricted. Security rules can be inconsistent across hostnames, regions, or failover paths. Error pages can be cached too broadly.

Performance failures are often more subtle. A site may have a CDN but still see poor results because assets are uncacheable, query strings fragment the cache, Vary headers are too broad, content is purged too often, or dynamic APIs dominate the page. A high cache hit ratio can also be misleading if the misses are concentrated on the pages that matter most.

The best CDN deployments are route-aware. They make public content fast and reusable, keep private content private, block unwanted traffic early, preserve enough evidence for troubleshooting, and keep the origin protected. A CDN is infrastructure, not a magic performance layer. Its value comes from clear policy and disciplined operation.