Design a CDN

Problem Statement

Design a Content Delivery Network (CDN) that caches and delivers static and dynamic content from edge servers distributed globally. The system must minimize latency by serving content from the nearest edge, handle cache invalidation efficiently, and protect origin servers from traffic spikes.

Requirements

Functional

• Cache static assets (images, JS, CSS, video) at edge locations closest to users
• Support cache invalidation: purge by URL, wildcard path, or cache tag
• Origin shield to consolidate cache misses and protect origin servers
• Support both push (pre-populate) and pull (lazy-fill) caching strategies

Non-Functional

• Latency: <50ms for cache hits, <200ms for cache misses (with origin shield)
• Cache hit ratio: Target 95%+ for static content
• Availability: 99.99% -- edge failures must be transparent to users
• Scale: 200+ global PoPs, 50 Tbps aggregate bandwidth

Core Architecture

1. Edge Server (PoP) -- Each Point of Presence runs a reverse proxy (e.g., NGINX/Varnish) with SSD-backed cache. Handles TLS termination, Brotli/gzip compression, and HTTP/2 push. Content is keyed by URL + Vary headers.

2. Origin Shield -- A mid-tier cache layer between edge and origin. All edge cache misses in a region route through a single shield node, collapsing duplicate requests. Reduces origin load by 90% during cache invalidation storms.

3. DNS-based Global Traffic Manager -- Resolves CDN domains to the nearest healthy PoP using GeoDNS and latency-based routing. Health checks run every 10s; unhealthy PoPs are removed from DNS within 30s.

4. Purge Propagation Service -- Receives purge requests and fans them out to all 200+ PoPs via a pub/sub system (Kafka). Supports instant purge (delete from cache), soft purge (mark stale, serve while revalidating), and tag-based purge.

Database Choice

Edge cache storage: Local SSD + in-memory LRU for hot objects. No centralized database for content. Configuration and routing rules: stored in etcd with replication to every PoP. Access logs and analytics: streamed to Kafka, aggregated in ClickHouse for real-time dashboards (bandwidth, cache hit ratio, error rates by PoP).

Key API Endpoints

POST /api/v1/purge
  -> Body: \{ type: "url" | "wildcard" | "tag", value: "/images/*", soft: false \}

GET /api/v1/analytics/\{domain\}?range=1h
  -> Returns: \{ requests: 1.2M, cache_hit_ratio: 0.96, bandwidth_gb: 450 \}

PUT /api/v1/origins/\{domain\}
  -> Body: \{ origin: "origin.example.com", shield_region: "us-east", ttl_default: 86400 \}

Scaling Insight

The origin shield pattern is the most critical scaling lever. Without it, a cache purge of a popular asset causes N simultaneous requests to the origin (one per PoP). With an origin shield per region, this collapses to 3-5 requests (one per shield). Combined with request coalescing (holding duplicate in-flight requests and serving all from one origin fetch), even viral content spikes generate minimal origin load.

Key Tradeoffs

Original DosiBridge notes for Design a CDN

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design a CDN is to connect the concept to a media-heavy path where network variance, buffering, and edge placement decide the user experience. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Core Entity: For Design a CDN, decide the core entity before choosing tools; otherwise the design looks clean but fails when design changes.
• Read/Write Path: For Design a CDN, decide the read/write path before choosing tools; otherwise the design looks clean but fails when cdn changes.
• Contention Point: For Design a CDN, decide the contention point before choosing tools; otherwise the design looks clean but fails when design changes.
• Abuse Path: For Design a CDN, decide the abuse path before choosing tools; otherwise the design looks clean but fails when cdn changes.
• Recovery Workflow: For Design a CDN, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when design changes.

Design a CDN correctness boundary

For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.

Design a CDN scaling bottleneck

The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.

Production review question

If Design a CDN suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?

Practical metric to track

Track design-cdn health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design a CDN, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

• Design a CDN -- Reference
• Source: System-Design-Overview