How would you design a global Content Delivery Network, or CDN, that serves static and dynamic content to millions of users worldwide? Walk me through the architecture, caching strategies, and how you would handle cache invalidation at scale.

Question

Accepted Answer

Designing a global CDN requires addressing several interconnected challenges. Let me walk you through my approach.

First, the core architecture. I would design a hierarchical edge network with three tiers. The first tier consists of Points of Presence, or PoPs, distributed across major metropolitan areas globally. Typically, you would need between fifty and two hundred PoPs for true global coverage. The second tier includes regional aggregation nodes that serve as intermediate caches between PoPs and origin servers. The third tier contains the origin shield layer, which protects origin servers from thundering herd problems.

For the caching strategy, I would implement a layered approach. At the edge level, PoPs would cache hot content using an LRU, or Least Recently Used, eviction policy with TTLs based on content type. Static assets like images and JavaScript files would get longer TTLs, typically twenty-four hours, while API responses would get shorter ones, around sixty seconds. At the regional level, the cache would handle less frequently accessed content, reducing origin load significantly.

Now, for the critical challenge of cache invalidation at scale. I would implement several complementary strategies. First, tag-based invalidation, where content is tagged during ingestion, allowing you to invalidate all content matching a specific tag. For example, invalidating all product images for a particular category. Second, soft purges, where instead of immediately deleting cached content, we mark it as stale. This allows continued serving of stale content while fetching fresh content in the background, preventing cache stampedes. Third, versioned URLs for immutable content. By embedding version hashes in URLs, you never need to invalidate these resources; you simply deploy new versions.

For geographic routing, I would use a combination of Anycast for DNS and a custom Global Server Load Balancing solution, or GSLB. Anycast naturally routes users to the nearest PoP, but we need GSLB for more intelligent decisions based on current PoP health and capacity.

Handling dynamic content is where it gets interesting. For personalized or dynamic content, I would implement edge computing capabilities. Edge functions can assemble personalized pages by combining cached page fragments with user-specific data, dramatically reducing origin requests.

For monitoring and failover, each PoP continuously reports health metrics to a central control plane. If a PoP becomes unhealthy, GSLB automatically redirects traffic to the next nearest healthy PoP within seconds.

The key trade-off in CDN design is consistency versus latency. For most content, eventual consistency is acceptable, which allows aggressive caching. But for transactional content where consistency matters, you either bypass the CDN or use shorter TTLs with aggressive invalidation.