What Is a Content Delivery Network (CDN)? How It Works in 2026

A content delivery network is a distributed set of edge servers that terminate user connections close to the requester, serve cached copies of your content, and fetch from origin only when they must. That last clause is where the economics live: in 2026, a well-tuned static asset workload runs a 92–98% edge cache hit ratio, meaning origin sees roughly one request in twenty. The difference between a 95% and a 99% hit ratio is a 5× change in origin egress and origin compute cost, which is why cache hit ratio, not "speed," is the number architects actually instrument.

This article gives you the request lifecycle end to end, the four CDN types and when each applies, the failure modes that take production down (they are rarely "the CDN was slow"), a cost model with current 2026 per-TB pricing, and threshold values you can instrument this week.

What is a content delivery network, and what does CDN stand for?

CDN stands for content delivery network. A content delivery network places servers in many network locations, peers or transits into the eyeball networks nearby, and answers requests from that local footprint instead of from a single origin region. Two things follow: round-trip time drops, and the origin stops being the bottleneck.

What changed by 2026 is the workload mix. The interesting traffic is no longer "static images." It is HLS and LL-HLS segment delivery, 40 GB game patch waves, container and model-weight distribution, API responses with short TTLs, and signed-URL protected downloads. Those workloads stress different parts of the stack: segment delivery stresses tail latency and cache fill concurrency; patch waves stress fill bandwidth and disk I/O at the edge; API caching stresses key normalization and purge propagation.

The definition engineers actually use

Practically: a CDN is a programmable reverse-proxy tier you do not operate, sitting between clients and your origin, with a distributed cache, a routing layer, and a request/response manipulation layer. Everything else is implementation detail.

How does a CDN work? The request lifecycle, step by step

Follow one GET for a video segment from a client in Warsaw.

1. Resolution. The client resolves your hostname. It is a CNAME into the CDN's zone. The CDN's authoritative resolver answers with an address selected from the resolver's subnet or the client subnet passed in ECS. Anycast operators return the same address everywhere and let BGP pick the PoP; unicast-DNS operators return a region-specific address. Anycast reacts to network failure in seconds without DNS TTL lag; DNS steering gives finer-grained control over which PoP absorbs which traffic. Most large networks in 2026 run a hybrid.
2. Connection. TCP or QUIC handshake to the edge, then TLS. Session resumption and 0-RTT matter more than people expect on segment-heavy workloads, where a player opens and reuses connections across hundreds of short requests. HTTP/3 adoption across delivery traffic passed the majority mark for browser clients by 2026; HTTP/2 remains dominant for server-to-server and older native players.
3. Cache key construction. The edge builds a key from host, path, and whatever query parameters and headers the config says are significant. This is where most hit-ratio loss happens. An unfiltered marketing parameter or a Vary on User-Agent will shred a hit ratio from 96% to under 50% without any error appearing in your dashboards.
4. Cache lookup. Hit: served from NVMe or RAM, single-digit milliseconds, no origin involvement. Stale-but-revalidatable: served immediately, revalidated in the background. Miss: proceed.
5. Collapse and fill. A correctly configured edge coalesces concurrent misses for the same key into a single upstream request. Without request collapsing, a cold popular object produces a thundering herd against origin. This is the single most common cause of "the CDN caused an origin outage."
6. Mid-tier / origin shield. The fill goes to a designated shield tier rather than straight to origin. On a 30-PoP footprint, shielding typically cuts origin requests by 60–85% on long-tail catalogs, because the shield absorbs the per-PoP first-miss tax.
7. Origin response and storage. Origin returns the object with cache-control directives. The edge stores it, applies compression or range-slicing for large files, and returns it. Every subsequent request in that region is a hit until TTL expiry or purge.

Instrument step 3 and step 6. Everything else is visible in vendor dashboards by default; those two are where silent money leaks.

CDN types: which one fits which workload

A fifth category, multi-CDN, is an architecture rather than a product: two or more content delivery network vendors behind a steering layer that shifts traffic on real-user QoE telemetry. It is standard practice above roughly 500 TB per month, and it is also the most reliable way to hold pricing leverage at renewal.

Failure modes: how a content delivery network actually breaks production

This is the section most "what is a CDN" pages skip. In eight years of post-incident reviews across delivery platforms, CDN-adjacent outages cluster into five patterns, and only one of them is the CDN being down.

1. Cache key fragmentation

Someone adds a tracking parameter or a Vary header. Hit ratio collapses, origin request rate multiplies 10–20×, origin saturates, and the CDN faithfully passes through 502s. Detection: alert on hit ratio dropping more than 3 percentage points over a 15-minute window, not on absolute value.

2. Thundering herd on cold popular objects

A new game patch or episode drop goes live. Every PoP misses simultaneously. Without request collapsing and shielding, origin sees thousands of concurrent fills of the same object. Fix before the event, not during: pre-warm the shield tier and confirm collapsing is enabled per content type.

3. Purge storms

A deploy issues a wildcard purge across the whole catalog. Global cache empties, every subsequent request is a miss, origin absorbs full traffic for the duration of the refill. Use versioned paths or surrogate-key tagging so purges are surgical.

4. TLS and certificate expiry at the edge

Custom certificates on apex domains, SAN limits, and OCSP stapling failures produce hard client errors that look like network problems. Alert at 21 days to expiry, not 7.

5. Partial regional degradation

A single PoP or transit path degrades. Global averages stay green. Users in one metro see 4-second segment loads. Only per-ASN, per-metro percentile monitoring catches this. Median latency will lie to you; watch p95 and p99 segmented by network.

Threshold values worth alerting on

• Edge cache hit ratio below 90% for static content, or a 3-point drop in 15 minutes
• Origin offload below 85% for VOD catalogs
• p95 time-to-first-byte above 200 ms in any top-10 metro
• Origin 5xx rate above 0.1% of fill requests
• Rebuffer ratio above 0.5% for live, above 0.2% for VOD

What a CDN costs in 2026, and how to model it

Delivery pricing has bifurcated. Hyperscaler CDNs still price North America and Europe egress in the $0.02–$0.085 per GB range depending on commitment, which is $20–$85 per TB. Volume-focused content delivery network providers land between $2 and $10 per TB. For a 300 TB/month media workload, that spread is the difference between roughly $6,000 and roughly $1,000 a month for the same bytes.

Build the model on four inputs: monthly egress in TB, origin fill volume (egress divided by offload ratio), request count for any per-request billing, and the cost of the engineering time to maintain the config. The fourth input is what makes multi-CDN worth it only above a certain volume, since the steering layer and the QoE telemetry pipeline are not free.

Within the high-volume cost-at-scale set — Bunny.net, CDN77, KeyCDN, Gcore, Medianova, and Fastly for streaming-heavy work — the trade-offs are real. Fastly's instant purge and edge compute maturity are genuinely strong for teams doing heavy request manipulation. Bunny and KeyCDN are hard to beat on simplicity for smaller footprints. Gcore brings broad geographic reach.

BlazingCDN's volume pricing sits at the aggressive end of that set, starting at $5 per TB ($0.005 per GB) and scaling to $2 per TB ($0.002 per GB) at 2,000 TB and above, with commit tiers at $100 for 25 TB, $350 for 100 TB, $1,500 for 500 TB, $2,500 for 1,000 TB and $4,000 for 2,000 TB. It runs NVMe SSD edge storage, holds 100% uptime, absorbs demand spikes without renegotiation, and delivers stability and fault tolerance comparable to Amazon CloudFront at a fraction of the per-TB cost — which is the whole argument for enterprises and large corporate clients moving petabyte-scale catalogs. Onboarding is typically about an hour, which matters if you are validating it as a second lane in a multi-CDN setup rather than a full migration.

FAQ

What does CDN stand for?

CDN stands for content delivery network. Some vendors use "content distribution network" interchangeably; there is no technical distinction. The term describes the distributed edge caching and routing tier, not any specific protocol or product.

What is a content delivery network used for beyond static files?

Streaming segment delivery, large binary distribution such as game patches and container images, API response caching with short TTLs, TLS termination close to users, and edge compute for routing and token validation. As of 2026, video and large-file distribution account for the majority of CDN bytes moved.

Does a CDN help if my users are all in one country?

Yes, but for different reasons. The latency gain shrinks, while origin offload, connection termination, burst absorption during traffic spikes, and egress cost reduction remain. Single-region sites with heavy media catalogs often see the strongest ROI from offload alone.

How do I measure whether my CDN is actually working?

Three numbers: edge cache hit ratio, origin offload percentage, and p95 time-to-first-byte segmented by metro and ASN. Global averages hide regional degradation. If you only track one, track hit ratio trend deltas rather than absolute values.

Is multi-CDN worth the complexity?

Below roughly 500 TB per month, usually not — the steering layer, telemetry pipeline, and config drift cost more than they save. Above that, it buys availability during single-vendor incidents and real pricing leverage at renewal.

Why does my cache hit ratio drop after a deploy?

Almost always cache key changes or wildcard purges. Check whether new query parameters entered the key, whether a Vary header was added, and whether your deploy pipeline is issuing broad purges instead of surgical, tag-scoped ones.

Run this benchmark this week

Pull 24 hours of edge logs and compute your cache hit ratio broken down by content type and by the top twenty cache keys by miss count. You will almost certainly find one key pattern generating a disproportionate share of misses, and it will be a query parameter you forgot to strip. Fix that one thing, measure the origin egress delta, and you will have a defensible number for what your content delivery network configuration is actually worth.

Then run the same object from two providers against real-user telemetry in your three largest metros at p95, not median. If you are curious how a lower-cost lane performs under your traffic shape, testing it as a secondary origin-shielded path is a one-afternoon experiment. What is your current offload ratio, and do you know it per content type or only in aggregate?