We've examined the individual components of CDN infrastructure—edge locations that serve users, origin servers that provide authoritative content. But a CDN is far more than the sum of these parts. The architecture that connects them—the routing decisions, caching hierarchies, control systems, and operational infrastructure—is what transforms scattered servers into a coherent global delivery network.

Understanding CDN architecture means understanding how a single user request flows through the entire system: from the initial DNS query, through intelligent routing, to cache lookup, potential origin fetch, and final response delivery. Each step involves engineering decisions that balance latency, consistency, cost, and reliability.

This page synthesizes our component-level understanding into a complete architectural view—the big picture that ties everything together.

At the highest level, a CDN consists of three major layers:

1. User-Facing Edge Layer — Distributed PoPs that receive user requests and serve responses
2. Mid-Tier Caching Layer — Regional caches, origin shields that aggregate and optimize requests
3. Origin Layer — Customer infrastructure where content originates

Surrounding these are supporting systems:

• Control Plane — Configuration management, health monitoring, routing decisions
• Data Plane — Actual content flow through caches and networks
• Analytics and Logging — Traffic analysis, debugging, billing data

1.1 Architectural Diagram Overview

A simplified CDN architecture:

┌─────────────────────────────────────────────────────────────────┐
│                        CONTROL PLANE                            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │ Config Mgmt  │  │ Health Check │  │ Analytics/Logging    │  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
└──────────────────────────┬──────────────────────────────────────┘
                           │ (pushes config, collects metrics)
┌──────────────────────────▼──────────────────────────────────────┐
│                         DATA PLANE                               │
│                                                                  │
│   USER ──DNS──▶ ┌────────────────────────────────────────────┐  │
│                 │           EDGE LAYER (300+ PoPs)            │  │
│                 │  ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐      │  │
│                 │  │PoP│ │PoP│ │PoP│ │PoP│ │PoP│ │PoP│ ...  │  │
│                 │  └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘      │  │
│                 └────┼─────┼─────┼─────┼─────┼─────┼────────┘  │
│                      │     │     │     │     │     │           │
│                 ┌────▼─────▼─────▼─────▼─────▼─────▼────────┐  │
│                 │      MID-TIER LAYER (Regional Caches)      │  │
│                 │      ┌───────┐    ┌───────┐    ┌───────┐  │  │
│                 │      │Shield │    │Shield │    │Shield │  │  │
│                 │      │ (US)  │    │ (EU)  │    │(APAC) │  │  │
│                 │      └───┬───┘    └───┬───┘    └───┬───┘  │  │
│                 └──────────┼────────────┼────────────┼──────┘  │
│                            │            │            │         │
│                 ┌──────────▼────────────▼────────────▼──────┐  │
│                 │              ORIGIN LAYER                  │  │
│                 │   ┌────────────────────────────────────┐  │  │
│                 │   │    Customer Origin Infrastructure  │  │  │
│                 │   │    (Web servers, Object Storage,   │  │  │
│                 │   │     API servers, etc.)             │  │  │
│                 │   └────────────────────────────────────┘  │  │
│                 └────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

Let's trace a complete user request through every layer of CDN architecture, examining the decisions and processing at each step.

2.1 Step 1: DNS Resolution

User action: Browser navigates to https://www.example.com/images/hero.jpg

What happens:

1. Browser checks local DNS cache → Miss
2. OS checks resolver cache → Miss
3. Query sent to configured DNS resolver (ISP, Google 8.8.8.8, Cloudflare 1.1.1.1)
4. Resolver checks its cache → Miss
5. Resolver queries root nameservers → Referred to .com TLD
6. Resolver queries .com nameservers → Referred to example.com authoritative NS
7. example.com NS is operated by CDN (delegated via CNAME or NS records)
8. CDN authoritative DNS server receives query

CDN DNS Server Processing:

Input: DNS query for www.example.com
  From resolver IP: 198.51.100.42
  EDNS Client Subnet: 192.0.2.0/24 (if provided)

CDN Logic:
  1. Map resolver/user IP to geographic location
  2. Check current health of PoPs in region
  3. Check current load/capacity of candidate PoPs
  4. Check customer-specific routing rules
  5. Select optimal edge IP address(es)

Output: A record pointing to edge PoP
  example: 104.16.132.229 (Cloudflare edge)
  TTL: 300 seconds

Critical decisions at this stage:

• Geographic proximity vs. current load
• PoP health (unhealthy PoPs excluded)
• Customer configuration (geo-restrictions, custom routing)
• Anycast vs. Unicast IP selection

2.2 Step 2: User Connection to Edge

What happens:

1. Browser receives edge IP from DNS
2. Browser initiates TCP connection to edge IP:443
   • SYN → Edge PoP
   • SYN-ACK ← Edge PoP
   • ACK → Edge PoP
   • (1 RTT consumed)
3. TLS handshake begins
   • ClientHello → Edge (cipher suites, SNI=www.example.com)
   • ServerHello, Certificate, ServerKeyExchange ← Edge
   • ClientKeyExchange, ChangeCipherSpec, Finished → Edge
   • ChangeCipherSpec, Finished ← Edge
   • (1-2 RTT consumed, depending on TLS version)

With TLS 1.3 and 0-RTT:

• Resumption can skip full handshake
• First request can piggyback on ClientHello
• Total connection setup: effectively 0-1 RTT

Edge server processing:

• TLS termination at edge (fast local decryption)
• SNI used to identify customer configuration
• HTTP/2 or HTTP/3 negotiated if supported

2.3 Step 3: Request Processing at Edge

HTTP Request received:

GET /images/hero.jpg HTTP/2
Host: www.example.com
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Cookie: session=abc123
User-Agent: Mozilla/5.0...

Edge Server Processing Pipeline:

1. Request Parsing

   • Parse HTTP headers
   • Validate request syntax
   • Extract key fields (Host, Path, Method)

2. Configuration Lookup

   • Map Host header to customer configuration
   • Load applicable rules, cache settings, security policies

3. Security Checks

   • WAF rule evaluation (SQLi, XSS patterns)
   • Rate limiting checks
   • Bot detection scoring
   • Geographic/IP restrictions
   • If blocked: return 403/503, exit flow

4. Request Modification (Edge Compute)

   • Execute customer edge functions if configured
   • Header manipulation
   • URL rewriting
   • Request routing decisions

5. Cache Key Generation

   • Construct cache key from:
     • Hostname + URL path + Query parameters (configurable)
     • Relevant Vary headers (Accept-Encoding, etc.)
     • Custom key components (device type, cookie values)
   • Example key: www.example.com|/images/hero.jpg|br

2.4 Step 4: Cache Lookup

Cache lookup sequence:

1. Memory Cache (hot tier)
   Key: www.example.com|/images/hero.jpg|br
   Result: MISS (not in memory)

2. SSD Cache (warm tier)  
   Key: www.example.com|/images/hero.jpg|br
   Result: HIT
   Object metadata:
     - Size: 234,567 bytes
     - Content-Type: image/jpeg
     - Cache-Control: max-age=31536000
     - ETag: "a1b2c3d4e5f6"
     - Age: 3600 (cached 1 hour ago)
     - Expires: far future

3. Freshness check:
   - max-age: 31536000 (1 year)
   - Current age: 3600 (1 hour)
   - Fresh? YES (3600 < 31536000)

Result: CACHE HIT - Serve from edge cache

2.5 Step 5: Response Delivery

Response construction:

HTTP/2 200 OK
Content-Type: image/jpeg
Content-Length: 234567
Cache-Control: max-age=31536000, public
ETag: "a1b2c3d4e5f6"
Age: 3600
CF-Cache-Status: HIT
CF-Ray: 7a1b2c3d4e5f6-IAD

<binary image data>

Response optimizations:

• Brotli/gzip compression if applicable
• HTTP/2 stream prioritization
• Concurrent streaming if file is large

Edge metrics update:

• Increment cache hit counter
• Log request details for analytics
• Update LRU metadata for cache management

What happens when content isn't in cache? Let's trace the cache miss flow, including mid-tier cache and origin fetch.

3.1 Local Cache Miss Detection

Continuing from Step 4 with a different scenario:

1. Memory Cache: MISS
2. SSD Cache: MISS
3. HDD Cache: MISS (or content expired)

Result: CACHE MISS - Must fetch from upstream

Decision point: Where to fetch from?

• If Origin Shield configured: Request goes to shield
• If no shield: Request goes directly to origin

3.2 Origin Shield Request (if configured)

Edge → Shield communication:

GET /images/hero.jpg HTTP/1.1
Host: www.example.com
X-Forwarded-For: 192.0.2.100
X-Forwarded-Proto: https
CF-Connecting-IP: 192.0.2.100
Accept-Encoding: gzip, br
If-None-Match: "old-etag" (if revalidating)

Shield processing:

1. Shield receives request from edge PoP
2. Shield checks its own cache:
   • HIT: Return cached content to edge
   • MISS: Fetch from origin

Shield cache advantage:

• Larger cache capacity than individual edges
• Serves multiple edge PoPs in region
• Higher hit ratio for long-tail content

Request coalescing at shield:

• Multiple edge requests for same object arrive simultaneously
• Shield holds subsequent requests while first fetch completes
• Single origin request serves all waiting edges
• Prevents origin storm during popular content expiration

3.3 Origin Fetch

Shield/Edge → Origin communication:

GET /images/hero.jpg HTTP/1.1
Host: www.example.com
X-Forwarded-For: 192.0.2.100, 104.16.132.229
X-Forwarded-Proto: https
X-Origin-Auth: <secret-token>
Accept-Encoding: gzip, br
If-None-Match: "old-etag" (conditional request)

Origin processing:

1. Validate authentication header
2. Process request (file lookup, database query, etc.)
3. Check if content modified since old-etag
4. Return response:
   • 200 OK + full content (new/changed)
   • 304 Not Modified (unchanged, validation success)

Origin response:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 234567
Cache-Control: max-age=31536000, public
ETag: "a1b2c3d4e5f6"
Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT
Vary: Accept-Encoding

<binary image data>

3.4 Response Caching and Propagation

Shield caching:

1. Receive origin response
2. Parse cacheability (Cache-Control, Expires, CDN config)
3. Store in shield cache with appropriate TTL
4. Forward response to requesting edge(s)

Edge caching:

1. Receive shield response
2. Store in appropriate cache tier (SSD/HDD based on size/access pattern)
3. Forward response to user

Total latency components (cache miss):

Modern CDNs implement sophisticated multi-tier caching to optimize for both speed (serve from fastest tier) and efficiency (maximize cache hit ratio). Understanding this hierarchy is essential for CDN optimization.

4.1 The Caching Pyramid

                         ┌─────┐
                         │ RAM │ ← Fastest, smallest (GB scale)
                        ┌┴─────┴┐
                        │  SSD  │ ← Fast, medium (TB scale)
                       ┌┴───────┴┐
                       │   HDD   │ ← Slower, large (tens of TB)
                      ┌┴─────────┴┐
                      │   Shield  │ ← Regional cache
                     ┌┴───────────┴┐
                     │    Origin   │ ← Authoritative source
                     └─────────────┘

Each tier has different characteristics:

4.2 Cache Tier Promotion and Demotion

Content moves between tiers based on access patterns:

Promotion (moving to faster tier):

• Object accessed multiple times in short window
• Frequency exceeds threshold for current tier
• RAM has available capacity

Demotion (moving to slower tier):

• Object not accessed within time window
• Tier capacity pressure requires eviction
• Newer/hotter content needs space

Access pattern examples:

4.3 Regional Tiering Strategies

Beyond single-server tiers, CDNs implement regional caching strategies:

Tiered Distribution:

• Small PoPs cache hot content locally
• Cache misses go to regional Super PoP
• Super PoP maintains larger cache
• Only Super PoP misses reach origin/shield

Example: Cloudflare Tiered Cache

User → Edge PoP → Regional Tier → Origin Shield → Origin
           ↓           ↓               ↓
        (Miss)      (Miss)          (Miss)
         ↓           ↓               ↓
      Check       Check           Check
      Regional    Shield          Origin

Benefits of regional tiering:

• Small PoPs can be deployed cheaply (limited cache needed)
• Regional caches absorb long-tail content
• Origin protection from geographically distributed requests
• Improved hit ratios without massive per-PoP storage

CDN architecture includes sophisticated routing systems that determine which edge serves each user, how requests flow through tiers, and how to handle failures or performance degradation.

5.1 Geographic Routing

The foundational routing strategy: serve users from nearby PoPs.

Implementation approaches:

DNS-Based Geo-Routing:

• Map resolver IP to location using geo-IP database
• Return IP of nearest PoP
• Works universally but resolution isn't exact
• EDNS Client Subnet improves accuracy

Anycast Routing:

• Same IP announced from all PoPs
• Internet routing sends packets to nearest announcing PoP
• No CDN routing logic needed—network handles it
• May not be optimal for performance (BGP shortest path ≠ lowest latency)

Performance-Based Routing:

• Measure actual latency between PoPs and user regions
• Route based on measured performance, not geographic distance
• Adapts to network conditions, congestion, failures
• More complex but more effective

5.2 Health-Aware Routing

Real-time health tracking:

• Control plane continuously monitors PoP health
• Failed health checks → PoP excluded from routing
• Graceful degradation during partial failures

Health check types:

• TCP port availability
• HTTP response from health endpoint
• Response content validation
• Latency threshold checks

Failure response:

Normal: User → PoP A (nearest, healthy)

PoP A fails health check:
  - DNS stops returning PoP A IPs
  - Anycast withdraws PoP A routes
  - Users automatically route to PoP B (next nearest)
  - Failover completes in seconds to minutes

5.3 Load-Aware Routing

Capacity-based routing decisions:

• Monitor PoP resource utilization (CPU, bandwidth, connections)
• Shift traffic away from overloaded PoPs
• Balance load across available capacity

Overflow handling:

PoP A at 90% capacity:
  - Reduce weight in DNS responses
  - New connections routed to PoP B
  - Existing connections complete normally
  - Gradual rebalancing as load changes

Spillover strategies:

• Least-connections routing
• Weighted round-robin with dynamic weights
• Predictive scaling based on traffic patterns

5.4 Content-Aware Routing

Some CDNs route based on content characteristics:

Compute-optimized PoPs:

• Requests requiring edge compute → PoPs with compute capacity
• Heavy WAF evaluation → PoPs with security specialization

Storage-optimized routing:

• Large file downloads → PoPs with high storage capacity
• Video streaming → PoPs with video optimization capability

Origin affinity:

• Requests for specific origins → PoPs with warm origin connections
• Reduces origin connection overhead

While the data plane handles actual content delivery, the control plane manages configuration, monitoring, and coordination across the global CDN infrastructure.

6.1 Configuration Management

Challenge: Distribute configuration changes to hundreds of PoPs within seconds.

Architecture patterns:

Push-Based Configuration:

• Central control plane pushes updates to all PoPs
• Fast propagation (seconds to minutes)
• Requires reliable delivery and acknowledgment
• Risk of partial propagation on network issues

Pull-Based Configuration:

• PoPs periodically pull configuration from central store
• Simpler implementation
• Slower propagation (poll interval dependent)
• Eventual consistency guaranteed

Hybrid Approach:

• Push notifications trigger immediate pull
• Periodic background sync ensures consistency
• Best of both: fast propagation with reliable convergence

Configuration versioning:

• Every config change gets unique version
• PoPs report running version
• Control plane tracks global consistency
• Rollback by reverting to previous version

6.2 Health Monitoring System

Distributed health checking:

• Each PoP continuously checks other PoPs
• Results aggregated to central system
• Consensus required for health state changes
• Prevents false positives from isolated checkers

Metric collection:

• Request success rates
• Response latencies (p50, p95, p99)
• Resource utilization
• Error codes and types
• Cache hit ratios

Alerting and automation:

• Anomaly detection on metrics
• Automated remediation for known issues
• On-call escalation for novel problems
• Incident management integration

6.3 Certificate Management

CDNs terminate TLS for millions of domains:

Certificate provisioning:

• Automated certificate issuance (Let's Encrypt, ACME)
• Custom certificate upload for enterprise customers
• Certificate validation and chain building

Certificate distribution:

• Certificates must reach all PoPs
• Private keys securely distributed
• Key rotation and renewal automation

Renewal automation:

• Track certificate expiration
• Trigger renewal 30+ days before expiry
• Validate new certificate
• Atomic cutover to new certificate
• Monitor for renewal failures

CDNs generate massive volumes of data—every request creates log entries, metrics, and telemetry. Making this data useful requires sophisticated analytics infrastructure.

7.1 Request Logging

Log fields captured per request:

• Timestamp
• Client IP (and geo location)
• Request URL, method, headers
• Response status, size, headers
• Cache status (hit/miss/expired)
• PoP identifier
• TLS version, cipher
• Response time breakdown (edge, origin, total)
• WAF decisions
• Bot score

Log volume challenges:

• Large CDNs process billions of requests/day
• Full request logging generates petabytes
• Storage, processing, and query costs significant
• Sampling strategies for cost management

Log delivery options:

• Real-time streaming (limited fields, for monitoring)
• Batch delivery (full logs, hourly/daily)
• Push to customer storage (S3, GCS, etc.)
• CDN-hosted analytics (aggregated, queryable)

7.2 Key Metrics for CDN Performance

Cache Efficiency Metrics:

• Cache Hit Ratio — % of requests served from cache
• Byte Hit Ratio — % of bytes served from cache (different due to file sizes)
• Cache Miss Rate — Inverse of hit ratio, origin load indicator

Performance Metrics:

• Time to First Byte (TTFB) — Time from request to first response byte
• Total Response Time — Complete request duration
• Origin Response Time — Time for origin to respond (cache misses only)

Availability Metrics:

• Error Rate — % of requests returning 4xx/5xx
• Availability — (1 - Error Rate) × 100
• Origin Error Rate — Errors from origin vs. CDN errors

Traffic Metrics:

• Request Rate — Requests per second
• Bandwidth — Bytes per second transferred
• Unique Visitors — Distinct client IPs

7.3 Real-Time Monitoring

Use cases:

• Detect outages within seconds
• Monitor traffic during launches/events
• Identify attacks as they begin
• Verify deployment success

Implementation:

• Edge servers report metrics every second
• Aggregation at regional level
• Global aggregation and alerting
• Dashboard latency: 10-60 seconds

Alert examples:

• Cache hit ratio drops below 80%
• Error rate exceeds 1%
• Request rate drops by 50%
• Origin response time exceeds 2 seconds

We've explored the complete architecture of Content Delivery Networks—from high-level structure to detailed request flows. Let's consolidate the key takeaways:

Module Complete:

You've now completed this foundational module on CDNs. You understand:

• Why CDNs exist — Distance creates latency; CDNs bring content to users
• What edge locations are — Globally distributed PoPs with specialized hardware and software
• How origins work — Authoritative content sources that edges cache and protect
• How it all fits together — The complete architecture from request to response

With this foundation, you're prepared to explore deeper CDN topics: caching mechanics, cache invalidation, origin shields, dynamic content acceleration, and CDN provider comparison.