Loading...
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Global CDN: 10 billion requests/day, roughly 115K QPS average, peaks at 5-10x during events. 50-200 PoPs worldwide, 5-50 edge servers per PoP. Target cache hit ratio: 95%+ for static content, 40-70% for dynamic. At 95% CHR, origin handles roughly 5,750 QPS (5% of 115K).
Petabytes of content cached globally, but each edge caches only the popular subset. Edge server: 1-10 TB SSD for cache, holding the hot set for its region. Content follows Zipf distribution: top 1% of URLs account for roughly 50% of requests. Average response size: 100 KB (mix of images, scripts, video segments).
Global CDN bandwidth: 10-100+ Tbps aggregate across all PoPs. Per-edge bandwidth: 10-40 Gbps. Compression reduces bandwidth by 60-80% for text-based content (HTML, CSS, JS).
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
A CDN has two distinct API surfaces: the HTTP caching protocol (Cache-Control headers, conditional requests, ETags) that governs how content flows between origin, edge, and browser, and the management API that lets operators configure distributions, purge caches, and monitor performance. The caching protocol is the real API of a CDN. The management API is the control plane.
Cache-Control headers control content freshness: max-age, s-maxage, no-cache, no-store, private, public. Conditional requests with If-None-Match (ETag) and If-Modified-Since enable efficient revalidation. The stale-while-revalidate and stale-if-error directives provide resilience without sacrificing user experience.
Example response headers from an edge server:
Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=300
ETag: "abc123def456"
X-Cache: HIT from edge-tokyo-01
Age: 1800
POST /api/distributions - Create a CDN distribution
PUT /api/distributions/:id/config - Update distribution config (origin, TTL rules)
POST /api/distributions/:id/purge - Purge cached content (by URL, wildcard, or tag)
GET /api/distributions/:id/analytics - Get cache hit ratio, latency, bandwidth metrics
POST /api/distributions/:id/purge
{
"type": "url",
"target": "/images/hero.jpg",
"invalidation_id": "inv-20260307-001"
}
GET /api/distributions/:id/analytics?range=1h
Response: {
"cache_hit_ratio": 0.953,
"p50_latency_ms": 8,
"p99_latency_ms": 45,
"bandwidth_gbps": 2.4,
"requests_per_second": 12500
}
Interview Tip
In an interview, start with Cache-Control headers (max-age, s-maxage, stale-while-revalidate) before REST management APIs. The HTTP caching protocol IS the CDN API. Interviewers expect you to know how content freshness is controlled. Candidates who jump straight to REST endpoints miss the core mechanism.
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
A CDN is an inverted tree. The origin server at the root holds authoritative content. An optional origin shield layer aggregates cache misses. Hundreds of edge PoPs at the leaves serve users worldwide. DNS routing (GeoDNS or Anycast) directs each user to their nearest leaf. The entire architecture exists to keep traffic at the edges and away from the root.
50-200 Points of Presence distributed globally, weighted by user density. Each PoP: 5-50 edge servers behind a local load balancer. Edge servers run: reverse proxy (Nginx/Varnish), local SSD cache, TLS termination, WAF/DDoS filtering. Each edge is stateless and can be replaced without data migration.
GeoDNS: returns different edge IPs based on client geographic location. European users get European PoP IPs.
Anycast: same IP address advertised from all PoPs. BGP routes to nearest PoP based on network topology. Simpler to manage (one IP, no per-region DNS config), automatic failover when a PoP stops advertising.
Latency-based routing: DNS service monitors RTT to each PoP and returns the lowest-latency option. More accurate than geography alone.
Intermediate cache layer between edges and origin. When multiple edges miss cache for the same content, the shield coalesces into one origin fetch. Reduces origin load by 80-90% compared to edges fetching directly. Typically 2-5 shield locations per continent.
Authoritative content source: the truth. Behind the CDN, can be a simple fleet; does not need to handle user-facing scale. Only serves cache misses that pass through all cache tiers (roughly 2-5% of total traffic).
Health-check-aware routing: Unhealthy PoPs removed from DNS within seconds.
Auto-scaling: Additional edge capacity provisioned in hot regions during spikes.
Multi-CDN: NS records pointing to two CDN providers for provider-level redundancy.
Key Insight
Anycast routing: the same IP address is advertised from 200+ PoPs worldwide via BGP. The network routes each user's request to the nearest PoP automatically, with no per-user DNS logic needed. If a PoP goes down, it stops advertising the BGP route, and traffic shifts to the next nearest PoP within seconds. Anycast gives you geographic routing and automatic failover in a single mechanism.
Level Expectations
Mid: describe the edge-origin architecture and explain cache hit/miss flow.
Senior: explain origin shielding, request coalescing, and how cache key design affects hit ratio.
Staff: design a multi-CDN failover strategy with active health checks, reason about cache consistency vs. availability tradeoffs, and optimize cache warming for flash-sale scenarios.
Content delivery flow: DNS routes user to nearest edge. Cache hit serves in sub-10ms. Cache miss fetches from origin shield then origin, caches response, and serves user.
Understanding a CDN means tracing two flows: the content delivery flow (read path, how a user gets content from the nearest edge) and the cache invalidation flow (write path, how content updates propagate across all edges). The read path is optimized for speed. The write path is eventually consistent by design.
https://cdn.example.com/images/hero.jpgX-Cache: HIT and Age headers.Cache invalidation: Admin calls purge API. Control plane fans out invalidation to all edge PoPs via message queue. Each edge deletes cached entry. Next request triggers fresh origin fetch.
POST /purge with type=tag and target=product-123Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
A CDN does not have a traditional database the way a social network or e-commerce platform does. The edge cache IS the primary data store, a distributed key-value store where the key is the cache key (URL + headers) and the value is the complete HTTP response. But the control plane needs persistent storage for distribution configs, routing rules, and analytics.
Cache Key: scheme + host + path + sorted_query_params + Vary headers
Value: {
http_status: 200,
headers: { "Content-Type": "image/jpeg", "ETag": "abc123", ... },
body: <binary content>,
metadata: { cached_at: timestamp, ttl: 3600, tags: ["product-123"] }
}
Storage: NVMe SSD, 1-10 TB per edge server. Data structure: Hash table with open addressing, or LSM-tree-based key-value store. Eviction: LRU (Least Recently Used) or LFU (Least Frequently Used) when cache is full. Index in memory, content on SSD. Hot objects promoted to RAM cache.
sql
CREATE TABLE distributions (
distribution_id UUID PRIMARY KEY,
domain VARCHAR(253) NOT NULL,
origin_url TEXT NOT NULL,
default_ttl INT DEFAULT 3600,
cache_behaviors JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_domain ON distributions(domain);
CREATE TABLE edge_config (
pop_id VARCHAR(50) NOT NULL,
distribution_id UUID REFERENCES distributions,
routing_weight INT DEFAULT 100,
is_active BOOLEAN DEFAULT true
);
Cassandra or ClickHouse for high-volume metrics: request count, CHR, latency, bandwidth per PoP per minute. Retain granular data for 7 days, roll up to hourly/daily for long-term.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
If the CDN architecture is the skeleton, the edge cache engine is the heart. Every request passes through the same critical decision point: is this content in cache (serve in sub-10ms) or not (fetch from origin at 200ms+)? This section deep-dives into the edge cache engine: the caching, coalescing, invalidation, and resilience mechanisms that determine whether the CDN delivers on its latency promise.
The cache hit/miss decision is the single operation that determines sub-10ms vs 200ms+ delivery. Every other CDN component exists to maximize hit ratio and minimize miss cost.
Default: scheme + host + path + sorted_query_params. Vary headers expand the key: Accept-Encoding, Accept-Language, custom headers. Common mistake: including tracking parameters in the cache key (utm_source, fbclid), which creates thousands of cache entries for identical content. Cache key normalization: lowercase host, sort query params, strip known tracking params.
Short TTL (5-30s): API responses, real-time data. High origin load, fresh content.
Medium TTL (300-3600s): HTML pages, product listings. Balanced freshness and efficiency.
Long TTL (86400s+): Versioned static assets (main.abc123.js). Maximum CHR.
stale-while-revalidate: serve stale immediately, revalidate in background. Best user experience for content where near-freshness is acceptable.
TTL and stale-while-revalidate: Fresh TTL serves immediately. Stale with SWR serves stale and fetches in background. Expired triggers synchronous origin fetch.
When a popular URL's TTL expires, hundreds of concurrent requests arrive at the edge simultaneously. Without coalescing: each request triggers a separate origin fetch, overwhelming the origin. With coalescing: first request triggers origin fetch. Subsequent requests for the same cache key are queued. When origin responds, response fans out to all waiting requests. One origin fetch serves hundreds of clients. Implementation: pending-request map keyed by cache key. Atomic check-and-insert to prevent races.
Shield is a regional cache (2-5 per continent) between edges and origin. Edge cache miss goes to shield cache check, then shield miss goes to origin fetch. Shield coalesces misses from multiple edges for the same content. Reduces origin traffic by 80-90% compared to direct edge-to-origin fetching. Shield also enables cross-PoP cache warming: if one edge fetches content through the shield, the shield has it cached for all other edges in the region.
Before flash sales: push known-hot content to edges in the affected region. Historical traffic analysis: identify top URLs by request count, pre-cache them. Rolling warm-up for new PoPs: gradually shift traffic, allowing cache to build organically.
Edge is the first line of defense: absorbs volumetric attacks before they reach origin. WAF rules filter application-layer attacks (SQL injection, XSS in query params). Rate limiting per source IP, per URL pattern, per region. Challenge pages (CAPTCHA) for suspicious traffic patterns. Anycast distributes attack traffic across all PoPs, so no single PoP absorbs the full attack.