CDN Architecture & Edge Computing: How Content Delivery Networks Actually Work

Every time a user loads your site, their request travels across the internet to reach your server — unless a content delivery network intercepts it first. Understanding CDN architecture is essential for building fast, reliable systems at scale.

How CDNs Work#

A CDN is a geographically distributed network of servers that caches and serves content closer to end users. Instead of every request hitting your origin server in us-east-1, the CDN serves responses from a nearby Point of Presence (PoP).

User (Tokyo) → PoP (Tokyo) → [Cache HIT] → Response (12ms)
User (Tokyo) → PoP (Tokyo) → [Cache MISS] → Origin (us-east-1) → Response (180ms)

The CDN reduces latency, offloads origin traffic, and improves availability.

PoP Architecture#

Each PoP typically contains:

• Edge servers — handle TLS termination, caching, and response delivery
• DNS routing — directs users to the nearest PoP via anycast or latency-based routing
• Health checks — monitor origin and failover automatically

Large CDNs operate 200+ PoPs worldwide. Cloudflare runs in 310+ cities; CloudFront operates 600+ edge locations.

Caching Strategies#

TTL (Time to Live)#

Cache-Control: public, max-age=86400, s-maxage=31536000

• max-age controls browser cache duration
• s-maxage controls CDN cache duration independently

Stale-While-Revalidate#

Cache-Control: public, max-age=60, stale-while-revalidate=3600

The CDN serves stale content immediately while fetching a fresh copy in the background. Users never wait for revalidation.

Cache Keys#

By default, CDNs cache based on URL path + query string. You can customize cache keys to include:

• Headers (e.g., Accept-Language for localized content)
• Cookies (e.g., A/B test variants)
• Device type (mobile vs. desktop)

Warning: over-segmenting cache keys destroys your hit ratio.

Cache Invalidation#

The two hardest problems in computer science — and one of them is cache invalidation.

# CloudFront invalidation
aws cloudfront create-invalidation \
  --distribution-id E1A2B3C4D5 \
  --paths "/api/*" "/blog/*"

Tag-based purging (Fastly's surrogate keys, Cloudflare's cache tags) is the most surgical approach — invalidate all objects tagged product-123 without blowing away unrelated cache.

Origin Shield#

An origin shield is an intermediate caching layer between edge PoPs and your origin server.

Edge (Tokyo)  ─┐
Edge (Seoul)  ─┤→ Origin Shield (us-west-2) → Origin Server
Edge (Sydney) ─┘

Without it, a cache miss at every PoP generates a separate origin request. With an origin shield, only one request reaches your origin per cache miss globally. CloudFront, Cloudflare, and Fastly all support this.

Edge Computing#

Modern CDNs go beyond caching — they run code at the edge.

Cloudflare Workers#

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/api/geo") {
      return new Response(JSON.stringify({
        country: request.cf.country,
        city: request.cf.city,
      }), { headers: { "Content-Type": "application/json" } });
    }
    return fetch(request);
  }
};

Lambda@Edge (CloudFront)#

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  // A/B testing at the edge
  const variant = Math.random() < 0.5 ? "a" : "b";
  request.uri = `/experiments/${variant}${request.uri}`;
  return request;
};

Vercel Edge Functions#

import { NextResponse } from "next/server";

export const config = { runtime: "edge" };

export default function handler(request: Request) {
  const country = request.headers.get("x-vercel-ip-country") ?? "US";
  return NextResponse.json({ country, timestamp: Date.now() });
}

Edge functions excel at: geo-routing, A/B testing, authentication, header manipulation, and personalization — all without a round trip to your origin.

Dynamic vs. Static CDN#

Modern architectures use both: static assets get immutable caching with hashed filenames, while dynamic content uses short TTLs with stale-while-revalidate.

CDN Tools Compared#

Multi-CDN Strategies#

Large-scale systems use multiple CDNs for resilience and performance:

DNS (latency-based routing)
├── Cloudflare (primary — 80% traffic)
├── CloudFront (failover — 15% traffic)
└── Fastly (specific regions — 5% traffic)

Benefits:

• Resilience — survive a CDN outage (yes, they happen)
• Performance — route to whichever CDN is fastest per region
• Negotiation leverage — avoid vendor lock-in

Tools like Cedexis (now Citrix ITM) and NS1 handle intelligent multi-CDN routing.

Key Takeaways#

1. Cache aggressively — use s-maxage and stale-while-revalidate liberally
2. Use origin shields — protect your origin from thundering herd
3. Prefer tag-based invalidation — surgical beats scorched-earth
4. Push logic to the edge — geo-routing, auth checks, and A/B tests belong at the PoP
5. Plan for CDN failure — multi-CDN or graceful degradation

CDN architecture is not just about speed — it is about building systems that scale globally without scaling your origin linearly.

---

Build production-grade systems with deep architectural knowledge — explore guides, tools, and more at codelit.io.

Explore more system design guides at codelit.io/blog.