Articles

CDN System Design Interview Guide: Edge Caching, Purging, Origin Protection, and Failover

Design a CDN for system design interviews: cache keys, TTLs, purging, stale serving, origin shielding, signed access, and multi-CDN failover.

A strong CDN system design interview answer should describe more than a box labeled “CDN.” Route each viewer to a healthy nearby edge, derive a safe cache key, serve fresh content locally, and collapse identical misses before they reach the origin. Use conditional revalidation or bounded stale serving when an object expires, propagate targeted purges through a separate control plane, and fail over only when the request is safe to retry.

The design must protect correctness as aggressively as latency. A high cache-hit ratio is worthless if the key mixes users, a purge leaves security-sensitive content accessible, or a failover sends a cold-cache storm to the origin.

This guide builds the CDN itself: edge caching, cache keys, revalidation, purging, origin shielding, restricted content, observability, and regional or multi-CDN failover.

How to Answer a CDN System Design Interview

Start with requirements, then separate the data plane from the control plane. The data plane handles viewer requests at high volume. The control plane changes cache policy, distributes signing keys, issues purges, monitors health, and steers traffic. Keeping them separate lets the request path stay fast even when an administrative service is degraded.

Clarify these points before drawing components:

Which content is immutable, mutable, personalized, private, or range-addressable?
What freshness delay is acceptable for HTML, APIs, images, and media segments?
Is availability more important than freshness during an origin outage?
Must a purge finish within seconds, or is versioned content sufficient?
Which failures require origin failover, regional failover, or a second CDN?

Define “success” as measurable targets: edge latency, request and byte hit ratios, origin offload, purge propagation, error rate, and recovery time. Do not promise an instant global purge or DNS switch; both are distributed operations.

Separate the CDN Data Plane from the Control Plane

The request path can be expressed as a short decision flow:

DNS, Anycast, or another traffic-steering layer selects a healthy CDN edge.
The edge terminates TLS and applies WAF, bot, rate, and signed-request checks.
It normalizes the request and computes the cache key.
A fresh hit is served immediately. An eligible stale object may be served while one worker revalidates it.
A miss is collapsed with equivalent misses and sent through a regional cache or origin shield.
The shield makes a conditional request to the primary origin, with a secondary origin available for safe retrieval requests.

The control plane stores versioned cache rules, origin definitions, certificates, signing keys, health state, and purge jobs. Each edge consumes signed configuration generations and continues using the last known good version if the control plane is temporarily unavailable.

Design Correct Cache Keys Without Destroying Hit Ratio

A CDN cache key is the identity of a reusable response. It normally begins with the request method and target URI, then adds only the query parameters, headers, cookies, locale, device class, or representation format that can change the response.

RFC 9111 explains how Vary adds request-header dimensions to response selection. Cloudflare’s cache-key documentation also warns that extra dimensions fragment the cache. This creates a central interview trade-off:

Omit a response-changing dimension and the CDN can serve the wrong variant.
Include unnecessary dimensions and one logical object becomes thousands of low-hit variants.

Use an allowlist of meaningful query parameters, normalize their order, and drop marketing parameters. Never place shared personalized content in cache unless the authorization boundary is deliberately represented and audited. Also cap cache-key cardinality: 100,000 URLs × five locales × three device classes × two formats already produces three million variants.

Choose TTLs, Revalidation, and Safe Stale Serving

Freshness is not the same as storage duration. A cache may evict an object before its TTL ends, and an expired object can sometimes remain useful. For shared caches, s-maxage is more specific than max-age; the Age header estimates how long ago a response was generated or validated.

When an object expires, send a conditional request with If-None-Match or If-Modified-Since. Under RFC 9110 conditional-request rules, an unchanged representation can return 304 Not Modified, refreshing metadata without retransmitting the body.

RFC 5861 defines two useful availability tools:

stale-while-revalidate serves bounded stale content while refreshing in the background.
stale-if-error permits bounded stale content when the upstream fails.

Use them for public content where a small freshness delay is acceptable. Avoid stale serving for authorization decisions, account state, prices that must be exact, or emergency removals unless the product explicitly accepts that risk.

Content type	Recommended policy	Main risk
Hashed static asset	Long TTL and immutable URL	Storage churn across versions
Mutable HTML	Short TTL, validators, bounded stale window	Briefly stale page
Public API response	Explicit key dimensions and short TTL	Cross-user leakage if keyed incorrectly
Personalized response	Usually bypass the shared cache	Lower origin offload
Large private media	Range support, long TTL, signed access	Signature or key fragmentation
404 response	Short status-specific negative TTL	Caching a transient failure

Design Purging, Cache Tags, and Versioned Assets

Versioned filenames are the normal deployment path for static assets. Amazon CloudFront recommends versioned names for frequently updated files because a new URL bypasses browser and intermediary caches, supports rollback, and avoids dependence on invalidation propagation.

Purging remains necessary for mutable documents, privacy events, legal removals, and emergencies. Support URL, prefix, tag, and full-distribution scopes, but make the narrowest scope the default. Tags or surrogate keys let a product update invalidate a page, its API representation, thumbnails, and localized variants without enumerating every URL.

A purge request should create a durable, idempotent job with an actor, reason, mode, targets, configuration generation, and per-provider acknowledgements. GET /v1/purges/{id} should expose partial completion rather than claiming global atomicity. Fastly’s soft-purge documentation shows the useful distinction: a hard purge makes the old object unusable, while a soft purge marks it stale so controlled revalidation can avoid a refill spike.

Protect the Origin from Miss Storms and Direct Access

Origin protection has two parts. Traffic protection limits how many cache misses become origin work. Access protection prevents clients from bypassing the CDN altogether.

Request collapsing elects one leader for simultaneous misses of the same key while other requests wait. Fastly’s request-collapsing guide notes both the benefit and the cost: it suppresses a thundering herd, but a slow or uncacheable leader can increase tail latency.

An origin shield or tiered cache aggregates misses from many edge locations. Amazon CloudFront Origin Shield, Cloudflare Tiered Cache, and Fastly shielding all implement this general pattern. Place the shield near the origin, retain a fallback path, and monitor whether it becomes a latency or concentration bottleneck.

For access control, keep the origin private or require CDN-to-origin authentication. Signed URLs suit individual files; signed cookies can cover many media segments. Viewer authorization and origin authorization are separate: a signed viewer request does not help if anyone can fetch the same object directly from a public origin.

Design Origin and Multi-CDN Failover

Failover is a policy decision, not a universal retry. Amazon CloudFront’s origin-failover behavior applies to configured errors and safe retrieval methods such as GET, HEAD, and OPTIONS; do not transparently replay arbitrary writes.

For multi-CDN resilience, synchronize certificates, hostnames, cache rules, signing keys, purge operations, security policies, and logs. A second CDN backed by the same failed origin is not full redundancy. A cold secondary can also shift a large miss wave to the origin at the worst possible time.

DNS health routing supports active-active or active-passive traffic, but failover is not instantaneous. Route 53’s TTL guidance explains that recursive resolvers cache answers: a longer TTL reduces DNS work but delays visibility of a routing change. Use health checks from several regions, failure thresholds, recovery hysteresis, and low-volume traffic on the secondary so readiness is continuously tested.

Estimate Capacity and Define CDN Observability

State assumptions aloud and calculate steady state plus an exceptional event. The following numbers are an interview exercise, not vendor performance claims.

Input or result	Interview assumption
Viewer requests	200 million/day, about 2,315 RPS average
Peak traffic	8× average, about 18,500 RPS
Average response body	120 KB; about 24 TB/day viewer transfer
Peak viewer bandwidth	About 2.22 GB/s
Request hit ratio	95%; about 925 peak origin requests/sec
Byte hit ratio	90%; about 2.4 TB/day origin fill traffic
Hot working set	500,000 objects × 120 KB, about 60 GB
Multi-CDN split	60/40; secondary must handle 2.5× its prior load after failover

Then stress the design. If one object owns 20% of peak traffic, a hard purge exposes roughly 3,700 requests per second at the edge. Collapsing and shielding reduce duplicate origin fetches, but the exact residual load depends on edge count and implementation.

Track request hit ratio and byte hit ratio separately; tiny objects can inflate one while large misses dominate cost. Also measure cache status, origin RPS and bytes, edge and origin TTFB at p50/p95/p99, key cardinality, shield hits, collapse waiter counts, purge acknowledgement latency, stale-after-purge probes, signature rejects, per-PoP errors, and cold-cache behavior after failover.

CDN System Design Interview FAQ

What should be included in a CDN cache key?

Include the method, normalized URL, and only the query parameters, headers, cookies, locale, or representation fields that can change the response. Exclude tracking parameters and irrelevant client attributes. The correctness test is simple: equivalent responses share a key, while responses that may differ never do.

When should you use a long TTL instead of purging?

Use a long TTL with content-hashed, immutable assets because changing the content creates a new URL. Use targeted purging for mutable URLs, emergency fixes, privacy events, or legal removals. Even then, keep validators and a sensible TTL so correctness does not depend exclusively on a globally distributed purge operation.

How do ETags reduce origin bandwidth?

An edge sends If-None-Match with the cached object’s ETag when revalidating. If the representation is unchanged, the origin can return 304 Not Modified without the response body. The request still reaches the origin, but metadata refresh is much cheaper than retransmitting a large object.

How do request collapsing and origin shielding differ?

Request collapsing combines concurrent misses for one cache key into one upstream fetch at a cache location. An origin shield adds a shared cache tier through which many edge locations funnel their misses. Together they reduce both simultaneous duplicate work and geographically distributed origin requests.

Is DNS-based multi-CDN failover instantaneous?

No. Health detection takes time, authoritative DNS must change its answers, and recursive resolvers may continue using cached records until their TTL expires. Design for a convergence window, keep the secondary warm and tested, and ensure the origin can survive the secondary CDN’s temporary cold-cache miss rate.

Final Takeaway

The best CDN system design interview answer makes correctness, freshness, and failure scope explicit. Build an HTTP-aware edge data plane; isolate purge, configuration, keys, and health in a control plane; use versioned assets, validators, bounded stale serving, collapsing, and shielding; and treat origin or multi-CDN failover as a controlled transition rather than magic.

Sources and Further Reading

Research note: This guide was checked on August 31, 2026. CDN behavior varies by provider and configuration; the cited standards and current provider documentation define the specific claims above.