CDN Architecture

What it is

A Content Delivery Network (CDN) is a globally distributed network of proxy servers (called Points of Presence, or PoPs) that cache and serve content from locations geographically close to end users. When a user requests a resource, their request is routed by Anycast DNS to the nearest PoP. If the PoP has the content cached (a cache hit), it serves the response locally at sub-10ms latency. If not (a cache miss), it fetches from the origin server, caches the response, and serves it. Subsequent requests for the same resource from the same PoP region are served from cache without touching the origin.

CDNs were originally designed for static assets (images, CSS, JavaScript, video), but modern CDNs like Cloudflare, Fastly, and AWS CloudFront are capable of caching dynamic API responses, terminating TLS at the edge, running application logic at PoPs (edge computing via Lambda@Edge or Cloudflare Workers), providing DDoS protection, and accelerating dynamic content through optimized private backbone networks between PoPs and origin.

Why it exists

Network latency scales with physical distance. A user in Tokyo hitting an origin server in Virginia experiences 180–220ms of round-trip latency purely from the speed of light, before any server processing time. A CDN PoP in Tokyo reduces that to under 5ms. For web applications, this difference is the gap between a responsive application and an unusable one. Studies consistently show that every 100ms of additional latency reduces conversion rates by 1–7%.

CDNs also act as a traffic multiplier for origin capacity. A single origin server that can handle 1,000 requests/second can effectively serve millions of requests/second if 99.9% are served from CDN cache. This is especially critical for viral traffic spikes (product launches, news events) where traffic can increase 1,000× in minutes — no amount of auto-scaling could respond fast enough, but CDN cache absorbs the load immediately. CDN infrastructure also provides inherent DDoS resilience: a globally distributed network with hundreds of Tbps of capacity can absorb volumetric attacks that would overwhelm any origin infrastructure.

When to use

• Your users are geographically distributed and latency to a centralized origin is a concern.
• You serve static or semi-static content (images, JS, CSS, fonts, API responses) that can be cached at the edge.
• Your application must handle traffic spikes that exceed origin capacity (product launches, viral content).
• You need DDoS mitigation and a security perimeter between the public internet and your origin servers.
• Origin bandwidth costs are significant — CDN cache offloads origin egress, which can reduce cloud egress bills substantially.
• You want to run lightweight application logic at the edge (A/B testing, auth token validation, geolocation-based redirects).

When not to use

• Purely private internal APIs where all clients are co-located with the origin — CDN adds cost and complexity with no latency benefit.
• All responses are highly personalized and vary per user/session with no shared cacheable fragments — CDN cache hit rate will be near zero.
• Your application handles highly sensitive data that must not be stored at third-party CDN infrastructure for compliance reasons.
• Real-time bidirectional communication (WebSockets, gRPC streaming) that cannot be meaningfully cached.

Typical architecture

  Global CDN Topology:
  User (Tokyo) ──► CDN PoP Tokyo ──HIT──► serve from edge cache
                        │
                       MISS (first request)
                        │
                        ▼
              Origin Shield (us-west-2)  ← single PoP that hits origin
                        │
                        ▼
                  Origin Server(s)

  Cache-Control Headers (origin response):
  Cache-Control: public, max-age=31536000, immutable  ← static assets w/ content hash
  Cache-Control: public, max-age=300, stale-while-revalidate=60  ← API responses
  Cache-Control: private, no-store  ← user-specific, never cache at CDN
  Surrogate-Control: max-age=3600  ← CDN-only TTL (stripped before browser)

  Edge Computing (Cloudflare Workers / Lambda@Edge):
  Request arrives at PoP
       │
       ▼
  Edge function runs:
    - validate JWT / auth token
    - A/B test assignment (no origin needed)
    - geolocation-based redirect
    - bot detection
    - request rewriting / URL normalization
       │
       ▼
  Serve from cache OR forward to origin

  Origin Shield (collapsed requests):
  100 concurrent cache misses for same key
       │
       ▼  Origin Shield
  1 request forwarded to origin
  99 requests wait for in-progress fetch
  All 100 served from shared result
          

Pros and cons

Implementation notes

Cache-Control header strategy: The most critical CDN configuration decision is setting correct Cache-Control headers on origin responses. For static assets with content-addressed URLs (filenames including a hash like app.a8f3b2.js), use max-age=31536000, immutable — the content never changes so it can be cached for one year. For dynamic API responses that can be shared across users, use public, max-age=300, stale-while-revalidate=60 — cached for 5 minutes with 60 additional seconds of stale serving while background revalidation occurs. For user-specific responses, use Cache-Control: private, no-store to prevent CDN caching. Use Surrogate-Control or CDN-Cache-Control headers for CDN-only TTLs that differ from browser cache TTLs.

Origin Shield: Enable origin shield (CloudFront's Origin Shield, Fastly's Shielding) to designate a single intermediate PoP as the last-hop before origin. This collapses concurrent cache misses: instead of 100 PoPs worldwide each sending a miss to the origin simultaneously, they all send misses to the shield PoP, which makes a single request to origin. Origin shield reduces origin request volume by 10–50× and prevents thundering herd on cache expiry. It also improves cache hit rates because popular content stays in the shield PoP's large cache even after it's evicted from smaller regional PoPs.

Common failure modes

• Caching private user data: Missing or incorrect Cache-Control: private headers cause CDN to cache user-specific responses and serve one user's data to another. Always explicitly mark private responses; this is a critical security vulnerability.
• Query string cache key misses: CDN includes query strings in cache keys by default; /api/products?sort=price and /api/products?sort=price&page=1 are separate cache entries. Normalize or strip irrelevant query parameters from cache keys to improve hit rates.
• Stale content after purge failure: Purge API rate limits (CloudFront: 3,000 paths/second) exceeded during mass invalidation; some PoPs continue serving stale content. Use surrogate keys / cache tags for bulk invalidation.
• Origin overwhelmed on CDN bypass: If CDN is bypassed (e.g., via direct origin IP), origin receives full traffic it was never sized to handle. Restrict origin access to CDN IP ranges only.
• Vary header fragmentation: Vary: Accept-Encoding causes CDN to store separate cache entries for gzip and brotli versions; Vary: User-Agent can fragment the cache into thousands of variants. Be deliberate about which Vary headers are necessary.

Decision checklist

• Cache-Control headers are set correctly on all origin responses: public/private, appropriate max-age per content type.
• Static assets use content-addressed URLs (hashed filenames) enabling long TTLs without invalidation complexity.
• Origin shield is enabled to protect origin from miss storms and reduce origin request volume.
• Cache key configuration (query parameters, headers, cookies) is reviewed to maximize hit rate without leaking private data.
• Cache purge/invalidation strategy is defined and tested for content update workflows.
• Origin access is restricted to CDN egress IP ranges to prevent direct origin bypass.
• Edge computing use cases (auth, redirects, A/B testing) have been evaluated for suitability vs. added CDN cost and complexity.

Example use cases

• Media streaming platform: Video thumbnails and metadata API responses are cached at CDN PoPs globally. 98% of requests are served from edge cache; the origin media server handles only unique content requests, reducing origin load by 50× and delivering sub-5ms thumbnail responses worldwide.
• E-commerce product pages: Server-side rendered product pages are cached at CDN for 60 seconds with stale-while-revalidate. During a flash sale, 100,000 concurrent users see near-identical pages served from edge; origin only handles 1 request per 60 seconds per PoP for each product page.
• SaaS API acceleration: A fintech SaaS routes all API traffic through Cloudflare. Static API documentation and webhook payloads are cached; dynamic requests benefit from Cloudflare's Argo Smart Routing, which uses the fastest network path between PoPs and origin, reducing P99 latency by 30% without any caching.

Related patterns

• Caching Strategies — CDN is a specialized form of cache; the same read-through pattern applies at network scale.
• Cache Invalidation — CDN cache purging is a specialized, globally-distributed invalidation challenge.
• Rate Limiting — CDNs provide edge rate limiting to protect origins from abuse before requests reach the application.

Further reading

• AWS CloudFront Developer Guide
• Cloudflare Cache Documentation
• web.dev — Content Delivery Networks