# Content Delivery Network Architecture: A Deep Technical Dive

## Blog Details

- **Author**: Naveen R.
- **Date**: September 20, 2026
- **Tags**: CDN, distributed systems, edge computing, caching, network architecture
- **Read Time**: 20 mins

## Introduction

Content Delivery Networks have become the invisible backbone of the modern internet, serving everything from streaming video to API responses with single-digit millisecond latencies. Yet their architecture remains poorly understood outside specialist circles. This post dissects the core systems that enable a global CDN to route, cache, and deliver content at scale.

We'll examine five interconnected subsystems: the hierarchical organization of edge infrastructure, cache invalidation mechanisms, origin protection through shielding, intelligent request routing, and TLS termination strategies. Each section builds from first principles while incorporating production patterns observed across modern CDN architectures.

This is written for senior engineers designing distributed systems, reviewing CDN vendor proposals, or building edge infrastructure. We assume familiarity with TCP/IP, HTTP semantics, and DNS fundamentals.

![High level architecture of a content delivery network where an end user is resolved by GeoDNS to the nearest edge PoP cache, an edge miss falls through to a regional shield cache and then to the origin server backed by an asset object store, with cache hits served directly from the edge.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/01-high-level-architecture.png)

![Globally scalable CDN where anycast routing spreads users across edge PoPs in the US, EU, and APAC, each PoP fills through a shared origin shield to the origin, and a control plane pushes cache rules to every edge.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/02-scalable-architecture.png)

## Edge Point of Presence Hierarchy

![Edge point of presence hierarchy where a user request checks an L1 edge cache, falls through to an L2 regional cache and then an origin shield before reaching the origin, and each tier fills down from the one above it.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/03-edge-pop-hierarchy.png)

### Three-Tier Architecture

Modern CDNs organize their infrastructure into three distinct tiers, each optimized for different trade-offs between coverage and cost.

**Tier 1: Edge PoPs** form the outermost layer, positioned in metro areas and internet exchange points for minimal last-mile latency. These locations prioritize geographic distribution over capacity. A typical edge PoP might contain 10-40 servers with 100-500TB of SSD cache. The cache stores only the hottest content, items requested frequently enough to justify the premium real estate and power costs of metro datacenter space.

**Tier 2: Regional PoPs** aggregate traffic from multiple edge locations. Positioned in major cloud regions, these facilities house 100-500 servers with petabyte-scale storage mixing SSDs for hot content and HDDs for the long tail. Regional PoPs serve two purposes: they act as a cache tier for content too cold for edge PoPs, and they shield origin servers from request amplification when edge caches miss.

**Tier 3: Origin Shield PoPs** sit immediately in front of origin infrastructure, collapsing concurrent identical requests into single origin fetches. These specialized facilities focus on request coalescing rather than geographic distribution.

### Cache Hierarchy Behavior

When a request arrives at an edge PoP, the system walks up the hierarchy on cache misses:

```
1. Client → Edge PoP (cache miss)
2. Edge PoP → Regional PoP (cache miss)
3. Regional PoP → Origin Shield (cache miss)
4. Origin Shield → Origin (fetch)
```

The response flows back down, with each tier caching according to its policy. This creates a natural heat-based distribution: viral content reaches edge PoPs, moderately popular content lives at regional tiers, and long-tail content either stays at the shield layer or requires origin fetches.

### Capacity Planning Considerations

Each tier operates under different constraints. Edge PoPs optimize for cache hit ratio on the top 1-5% of content by request volume. A well-tuned edge PoP might achieve 85-95% hit rates for static assets, but only if cache eviction policies correctly identify access patterns.

Regional PoPs target the next 10-20% of content, accepting lower per-request margins in exchange for shielding origin infrastructure. The economic model shifts: edge PoPs justify their cost through latency reduction, while regional PoPs justify theirs through origin bandwidth savings.

### Geographic Distribution Strategy

PoP placement follows internet user distribution and network topology, not uniform geographic coverage. High-value markets get dense edge PoP deployment (multiple locations within a single metro area), while lower-traffic regions might share a single regional PoP across multiple countries.

Peering relationships heavily influence placement. PoPs co-located at internet exchange points (IXPs) can serve requests without traversing expensive transit links. A server in an IXP facility can reach dozens of ISPs through direct peering, reducing both latency and bandwidth costs.

## Cache Invalidation and Purge

![Cache invalidation and purge where a content publisher calls the purge API by tag or URL, a purge coordinator broadcasts the invalidation over a fan-out bus, and every edge PoP receives and applies the purge.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/04-cache-invalidation-and-purge.png)

### The Fundamental Problem

Cache invalidation at CDN scale means coordinating state changes across thousands of servers in hundreds of locations, often with conflicting requirements: applications need immediate consistency, but physics limits how quickly information propagates globally.

### Purge Mechanisms

**URL Purge** removes specific objects identified by their full path. When a purge request arrives at a control plane, it must reach every PoP that might have cached the object. The naive approach broadcasts purge messages to all edge servers, but this scales poorly. Production systems typically implement a two-phase protocol:

```
1. Control plane logs purge request with timestamp T
2. Control plane sends purge to regional PoPs (seconds)
3. Regional PoPs propagate to their edge PoPs (seconds to minutes)
4. Edge servers mark cached object as stale
```

During propagation, some edge servers serve stale content while others fetch fresh copies. This creates a consistency window measured in seconds to minutes depending on CDN architecture.

**Tag-Based Purge** groups related content under arbitrary labels. When you upload a blog post with three embedded images, you might tag all four resources with "post-12345". Purging that tag invalidates everything atomically from the application's perspective, though the same propagation delays apply.

Tag-based systems maintain an inverted index mapping tags to URLs at each PoP. This consumes memory (potentially millions of tag-to-URL mappings) but enables powerful invalidation patterns. You can tag by user ID, content category, or application version, then purge entire classes of content with a single API call.

**Prefix Purge** invalidates all URLs matching a path prefix, like "/images/2024/*". This appears simple but creates implementation challenges. Cache keys often include query parameters, headers, and cookie values. A prefix purge must invalidate all variations, requiring either a full cache scan or a secondary index structure.

### Time-To-Live Strategy

Rather than relying on explicit purges, many systems use aggressive TTLs combined with cache revalidation. An object cached with "Cache-Control: max-age=60, stale-while-revalidate=3600" can be served for one minute, then triggers a background revalidation while continuing to serve the stale copy for up to an hour.

This pattern trades consistency for availability. Users might see content up to one minute stale under normal operation, but the system remains responsive even if origin servers slow down or fail. The edge continues serving stale content while attempting revalidation.

### Soft Purge vs Hard Purge

**Hard purge** immediately deletes cached objects. The next request must fetch from origin or an upstream cache tier, creating a thundering herd risk if the purged content is popular.

**Soft purge** marks content as stale but keeps it in cache. Edge servers immediately begin revalidating with origin, but serve stale content if origin is slow or unavailable. This provides graceful degradation: a soft purge followed by origin failure leaves the CDN serving stale content rather than error pages.

### Consistency Guarantees

CDN purge systems typically offer eventual consistency, not immediate consistency. The control plane guarantees that purge messages will reach all PoPs, but not when. This creates observable anomalies:

- User A updates an image, sees the new version (cache miss or purge completed at their edge PoP)
- User B in a different region still sees the old version (purge hasn't reached their PoP)
- Five seconds later, User B sees the new version (purge propagated)

Applications requiring stronger consistency must use cache-busting URLs (appending version numbers or content hashes) rather than relying on purge propagation.

## Origin Shielding

![Origin shielding where multiple edge PoPs on a miss route to a single designated shield PoP that coalesces concurrent requests into one origin fetch, and the origin fills the shield once.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/05-origin-shielding.png)

### Request Coalescing

Origin shielding solves a specific problem: when a popular object expires from edge caches simultaneously, hundreds of edge PoPs might simultaneously request it from origin, creating a traffic spike orders of magnitude larger than normal load.

An origin shield sits between edge PoPs and origin servers, collapsing concurrent identical requests into a single upstream fetch. When 500 edge PoPs simultaneously request the same expired object, the shield makes one origin request and multicasts the response to all waiting edge servers.

### Implementation Approaches

**Connection Pooling**: Shield servers maintain persistent connections to origin, reusing TCP connections across multiple client requests. This amortizes connection establishment overhead and enables better congestion control.

**Request Deduplication**: When a request arrives at the shield, the system checks if an identical request is already in-flight. If so, the new request waits for the existing fetch to complete rather than initiating a duplicate upstream request. This requires tracking in-flight requests by cache key (URL plus relevant headers).

**Negative Caching**: When origin returns an error, shields temporarily cache the error response to prevent error amplification. If origin returns 500 Internal Server Error, the shield might cache that response for 1-5 seconds, preventing a complete origin outage from generating a request storm.

### Shield Selection

Edge PoPs must choose which shield to use. Static assignment (edge PoP A always uses shield X) provides simplicity but creates availability risks. If shield X fails, edge PoP A must either fail over to a backup shield or connect directly to origin.

Dynamic shield selection monitors shield health and routes to the best available shield. This requires a control plane that tracks shield status and pushes routing updates to edge PoPs. The system must balance between shield affinity (routing to the same shield improves that shield's cache hit rate) and load distribution (spreading load across multiple shields).

### Geographic Shielding

For latency-sensitive dynamic content, a single global shield creates unacceptable latency for distant regions. Multi-region shielding places shields in multiple locations, with edge PoPs routing to their nearest shield.

This reintroduces the thundering herd problem at origin: if shields don't coordinate, multiple shields might simultaneously fetch the same content from origin. Some systems implement shield-to-shield communication, where shields check peer shields before fetching from origin, though this adds complexity and latency.

### Shielding Trade-offs

Origin shielding adds latency: every request pays an extra network hop. For cache hits at the edge, shielding is irrelevant. For cache misses, shielding adds 10-50ms depending on edge-to-shield distance.

The trade-off makes sense when origin protection is more valuable than per-request latency. A cache miss rate of 5% with 1000 requests/second means 50 requests/second hit origin. Without shielding, if those 50 requests/second distribute across 200 edge PoPs, origin sees highly variable traffic with poor connection reuse. With shielding, origin sees a smooth 50 requests/second from a few shield IPs with excellent connection reuse.

## Request Routing with Anycast and GeoDNS

![Request routing where a user is directed to the nearest healthy PoP either by GeoDNS using a latency map or by anycast BGP taking the shortest network path, and a health and load signal reroutes to a failover PoP when one is overloaded or down.](https://d5osvdbc8um23.cloudfront.net/static-asset/blog_images/system-design-cdn/06-request-routing.png)

### The Routing Problem

When a client requests "cdn.example.com", the CDN must route that client to an optimal PoP. "Optimal" is multidimensional: lowest latency, sufficient capacity, healthy servers, and ideally a PoP with the requested content already cached.

### Anycast Routing

Anycast assigns the same IP address to servers in multiple locations. When a client sends a packet to an anycast IP, internet routing protocols deliver it to the topologically nearest server advertising that IP.

**Implementation**: Each PoP advertises the CDN's anycast IP prefixes via BGP to its upstream networks. Internet routers select the shortest AS path, naturally routing clients to nearby PoPs.

**Advantages**: Anycast routing happens at the network layer, requiring no application-level logic. Latency is typically optimal since internet routing protocols minimize AS path length, which correlates with latency. DDoS traffic naturally distributes across all PoPs rather than concentrating on a single location.

**Limitations**: Anycast provides no application-layer awareness. A PoP might be overloaded or experiencing issues, but anycast continues routing traffic there until BGP advertisements withdraw. Anycast offers no session affinity: if routing changes mid-connection, the client suddenly communicates with a different PoP, breaking stateful protocols.

### GeoDNS Routing

GeoDNS returns different DNS answers based on the client's geographic location. When a client queries "cdn.example.com", the authoritative nameserver examines the client's IP address, determines its location, and returns an IP address for a nearby PoP.

**Implementation**: The DNS server maintains a mapping of IP prefixes to geographic locations and a mapping of locations to PoP IP addresses. For each query, it performs a longest-prefix match on the client IP to determine location, then returns the optimal PoP IP for that location.

**Advantages**: GeoDNS enables application-layer routing decisions. The DNS server can consider PoP health, capacity, and even cache contents when selecting a PoP. GeoDNS provides session affinity through DNS TTLs: a client continues using the same PoP IP until the DNS record expires.

**Limitations**: GeoDNS depends on accurate IP geolocation databases, which have errors. Mobile clients and VPN users appear in unexpected locations. DNS resolution happens once per TTL period, so routing can't react quickly to changing conditions. Client-side DNS caching and forwarding resolvers obscure the true client location.

### Hybrid Approaches

Production CDNs typically combine both techniques. Anycast provides the base layer: clients resolve "cdn.example.com" to an anycast IP that routes them to a nearby PoP via BGP. GeoDNS adds application-layer control: the CDN can steer specific clients to specific PoPs by returning unicast IPs instead of anycast IPs when needed.

This hybrid model enables sophisticated routing:
- Normal clients get anycast IPs and route via BGP
- Clients in regions with PoP issues get unicast IPs for healthy alternate PoPs
- High-value clients get unicast IPs for premium PoPs with better peering

### Latency-Based Routing

Beyond geography, some systems implement latency-based routing. The DNS server periodically measures latency from various vantage points to each PoP, building a latency matrix. When a client queries, the server returns the PoP with the lowest measured latency to that client's region, not just the geographically nearest.

This handles cases where geographic proximity doesn't match network proximity. A client in Singapore might get lower latency to a Tokyo PoP with excellent peering than to a Singapore PoP with poor connectivity.

### Capacity-Aware Routing

As PoPs approach capacity limits, the routing system must divert traffic. The simplest approach withdraws BGP announcements from overloaded PoPs, causing anycast to route traffic elsewhere. This is coarse-grained: the PoP either receives traffic or doesn't.

GeoDNS enables gradual load shedding. As a PoP approaches capacity, the DNS server reduces the percentage of queries answered with that PoP's IP. A PoP at 80% capacity might receive 50% of its normal traffic share, with the remainder distributed to nearby PoPs.

## TLS Termination at the Edge

### Why Terminate at the Edge

TLS termination at edge PoPs rather than origin servers provides three benefits: reduced latency, reduced origin load, and centralized certificate management.

**Latency reduction**: TLS handshakes require multiple round trips. TLS 1.3 requires one round trip for a full handshake (ClientHello → ServerHello, Certificate, Finished → Finished) and zero round trips for session resumption. Terminating at the edge means these round trips traverse only the client-to-edge path, not the full client-to-origin path. For a client 20ms from an edge PoP but 150ms from origin, this saves 260ms on full handshakes and 300ms on non-resumed connections.

**Origin offload**: TLS encryption and decryption consume CPU. Offloading this to edge servers frees origin capacity for application logic. Modern CPUs with AES-NI instructions make symmetric encryption cheap, but the asymmetric operations during handshakes (RSA decryption or ECDHE key agreement) remain expensive at scale.

**Certificate management**: Centralizing certificates at the CDN simplifies operations. Origin servers need certificates only for CDN-to-origin connections, which can use a single long-lived certificate. Client-facing certificates, which require frequent rotation and may need per-hostname certificates for SNI, are managed entirely by the CDN.

### Handshake Optimization

**Session Resumption**: TLS session tickets allow clients to resume previous sessions without a full handshake. The server encrypts session state into a ticket and sends it to the client. On subsequent connections, the client presents the ticket, and the server resumes the session after validating the ticket.

At CDN scale, session tickets create a coordination problem. If a client's ticket was issued by edge server A but their next request routes to edge server B, server B must be able to decrypt and validate the ticket. This requires either:

1. Shared ticket encryption keys across all edge servers in a PoP
2. Sticky routing to ensure clients return to the same edge server
3. Stateless tickets with session state encrypted using a key known to all servers

Most CDNs implement option 3, distributing ticket encryption keys to all edge servers. Keys rotate periodically (every few hours) for security, with a grace period where both old and new keys are accepted.

**OCSP Stapling**: Clients verify certificate validity by checking certificate revocation status. The naive approach requires clients to contact the Certificate Authority's OCSP responder, adding latency and creating privacy concerns. OCSP stapling allows the server to fetch the OCSP response and include it in the TLS handshake.

Edge servers periodically fetch OCSP responses for their certificates and cache them. During handshakes, they include the cached response, eliminating the client's need to contact the CA. This reduces handshake latency and improves privacy.

**TLS 1.3 Benefits**: TLS 1.3 reduces handshake round trips from two to one for full handshakes and enables zero-RTT resumption. Zero-RTT allows clients to send encrypted application data in the first flight of a resumed connection, eliminating the resumption round trip entirely.

Zero-RTT introduces replay attack risks: an attacker can capture and replay the client's first flight, causing the server to process the request multiple times. CDNs mitigate this by restricting zero-RTT to idempotent requests (GET, HEAD) and implementing replay detection using a combination of timestamps and request deduplication.

### Certificate Management at Scale

**SNI and Multi-Tenancy**: Server Name Indication (SNI) allows a single IP address to serve multiple domains with different certificates. The client includes the requested hostname in the TLS ClientHello, and the server selects the appropriate certificate.

CDNs serve thousands of customer domains from shared edge servers. Each server must have access to certificates for all domains it might serve. This creates a distribution problem: how do you securely distribute hundreds of thousands of certificates to thousands of edge servers?

**Certificate Storage**: Edge servers maintain a local certificate cache, loading certificates from a central certificate store on demand. When a ClientHello arrives for an unknown hostname, the edge server fetches the certificate from the central store, caches it locally, and completes the handshake. Subsequent requests for that hostname use the cached certificate.

The central store must be highly available: if it's unreachable, edge servers can't obtain certificates for new hostnames. Most implementations replicate the certificate store across multiple regions and cache certificates at edge servers for extended periods (hours to days) to tolerate central store outages.

**Automated Certificate Issuance**: Managing certificates for millions of domains requires automation. CDNs integrate with ACME (Automated Certificate Management Environment) to automatically issue and renew certificates. When a customer adds a domain, the CDN:

1. Initiates an ACME order with a Certificate Authority
2. Completes domain validation (typically HTTP-01 or DNS-01 challenge)
3. Receives the issued certificate
4. Distributes it to edge servers
5. Schedules automatic renewal before expiration

### Edge-to-Origin Encryption

Terminating TLS at the edge doesn't eliminate the need for encryption. Edge-to-origin connections typically use TLS to protect data in transit across the internet or cloud provider networks.

**Certificate Validation**: Edge servers validate origin certificates to prevent man-in-the-middle attacks. This requires edge servers to have access to trusted root certificates and to perform certificate chain validation and hostname verification.

For origin servers behind the CDN's shield, some operators use mutual TLS (mTLS), where both edge and origin present certificates. This provides strong authentication: the origin can verify that requests come from legitimate CDN edge servers, not attackers who discovered the origin IP.

**Connection Reuse**: Edge servers maintain connection pools to origin, reusing TLS connections across multiple client requests. This amortizes the handshake cost across many requests. A connection pool might maintain 10-100 persistent connections per edge server to origin, with connections living for minutes to hours.

## Conclusion

Content delivery networks represent a fascinating intersection of distributed systems theory and practical engineering. The architecture described here, from hierarchical caching to anycast routing to edge TLS termination, reflects decades of evolution driven by the relentless demands of internet-scale traffic.

Several themes emerge across these subsystems. First, the tension between latency and consistency: aggressive caching reduces latency but complicates invalidation. Second, the value of hierarchical design: three-tier PoP architectures and shield layers protect origin infrastructure while maintaining edge performance. Third, the importance of graceful degradation: soft purges, stale-while-revalidate, and negative caching keep systems responsive during partial failures.

For engineers building on or integrating with CDNs, understanding these internals clarifies the trade-offs embedded in CDN APIs and configurations. Cache TTLs, purge propagation delays, and TLS handshake optimization aren't arbitrary parameters but reflections of fundamental distributed systems challenges.

The CDN architecture presented here is not the only valid design. Different operators make different trade-offs based on their traffic patterns, cost structures, and reliability requirements. But the core problems, request routing, hierarchical caching, origin protection, and edge termination, remain consistent across implementations. Understanding these foundations enables informed decisions whether you're selecting a CDN vendor, tuning an existing deployment, or building edge infrastructure from scratch.