Content Delivery Networks (CDNs)
A CDN places cache and proxy capacity near users, terminating connections and serving content from points of presence. Beyond static files, modern CDNs provide TLS, DDoS protection, WAF, request routing, image/video transforms, edge compute, and origin shielding. Senior candidates design cache keys, purge/versioning, authorization, range behavior, origin capacity, multi-CDN failover, and edge observability.
How to use this chapter
- Read the mental model and mechanics without taking notes.
- Close the page and explain the topic aloud in five minutes.
- Work the quantitative example on paper.
- Answer the question ladder without revealing the answer signals.
- Complete one design drill and score yourself with the senior checklist.
Learning objectives
- Explain PoPs, edge caches, origin, cache fill, anycast/DNS steering, and tiered/origin-shield caching.
- Design cache-control, cache keys, immutable assets, purge, revalidation, and stale behavior.
- Handle dynamic/personalized content, signed URLs/cookies, ranges, streaming, and compression.
- Protect origins with shielding, request collapsing, rate limits, WAF, and DDoS controls.
- Quantify hit ratio, byte hit ratio, egress, fill amplification, and regional performance.
- Plan multi-CDN, edge-compute, security, and incident response at senior level.
Mental model
A CDN is a globally distributed reverse proxy and cache. A user is routed to an edge location, where the CDN may terminate TLS, apply policy, and answer from cache. On a miss, it fetches from an upper tier or origin, stores according to cache rules, and returns the response. The edge sees enormous fan-out; the origin should see only controlled misses.
Core mechanics
Edge routing and PoPs
CDNs use DNS, anycast, or both to route clients to a suitable point of presence based on network topology, latency, capacity, and health. The closest geographic PoP is not always the lowest-latency network path. Connections may stay pinned while routing changes affect only new flows.
Each PoP has finite cache, network, and compute capacity. Rare content may miss at many PoPs; popular content becomes hot locally. Regional incidents, ISP peering, and address-family differences require performance metrics by PoP/ASN, not a global average.
Cache hierarchy and origin shield
Without hierarchy, the first request at every edge PoP can hit origin. Tiered caching or an origin shield makes many edges fetch through a smaller set of upper-tier caches, increasing reuse and controlling origin connections. It can also create a concentrated dependency and extra latency on misses.
Request collapsing ensures concurrent misses for the same key share one fill. Protect the origin with authentication, allowlists/private connectivity where possible, connection pooling, rate limits, and capacity for the planned miss rate plus failover.
Cache-control and keys
Use immutable versioned URLs for build assets and long freshness (max-age, shared-cache directives, immutable semantics as supported). Mutable content uses shorter freshness, validators, targeted purge, or stale-while-revalidate. Separate browser-cache policy from CDN-cache policy when standards/provider controls permit.
Cache keys commonly include scheme/host/path/query and selected headers/cookies. Normalize query parameters, strip tracking noise, and include all content-varying dimensions. Personalized or authorization-bearing requests need bypass, private caching, signed access, or controlled key partitioning.
Invalidation, purge, and versioning
Purge can remove a URL, tag/surrogate group, prefix, or entire zone depending on provider. Global purge has propagation time and can trigger a miss storm. Versioned content avoids purge for immutable assets: publish new URL, update references, then retire old versions through lifecycle rules.
For mutable objects, soft purge/revalidation can preserve stale fallback. Use generation metadata and prevent an older origin response from refilling after a newer purge/version. Test purge under load and monitor origin fill rate.
Dynamic and personalized delivery
CDNs still improve dynamic content through connection reuse, TLS offload, optimized routing, compression, WAF, and edge logic even when responses are not cached. Some fragments or APIs can be cached by public data dimensions while private parts are assembled at edge or client.
Edge compute can authenticate, route, transform, personalize, and run A/B logic. Keep it small, deterministic, and observable; distributed edge deployments magnify configuration bugs and have runtime/storage limits. Authoritative transactional writes normally remain at a controlled regional service.
Media, ranges, and large objects
Video and large downloads use range requests and segmented formats. Cache segments independently, preserve validators, and avoid origin work per byte-range when the storage backend can serve ranges. Signed URLs/cookies grant time-limited access without routing every byte through the application.
Image/video transformation at edge can reduce origin variants but creates a cache-key explosion and compute-abuse risk. Restrict allowed dimensions/formats, canonicalize transformations, cap source size, and pre-generate popular variants.
Security at the edge
The CDN can absorb volumetric attacks, apply WAF/bot rules, rate limits, TLS policy, and request normalization. The origin must reject direct unauthenticated traffic; otherwise attackers bypass the edge. Use mutually authenticated connections, signed origin requests, private origin access, or strict source controls.
Configuration is security-sensitive. A cache rule can leak private data; a header rewrite can break auth; a WAF rule can block all traffic. Use code review, staged PoPs/traffic, synthetic tests, audit logs, and fast rollback.
Multi-CDN and operations
Multi-CDN can reduce provider/peering risk and improve bargaining/performance, but doubles configuration, logs, certificates, purge APIs, analytics, and behavior differences. A traffic manager may use DNS or client steering. Ensure both providers are warm enough and the origin can withstand failover miss load.
Track request hit ratio, byte hit ratio, origin fetches, fill latency, stale serves, cache-status, WAF decisions, edge errors, TLS handshake, PoP/ASN performance, and purge propagation. Correlate edge and origin request IDs.
Decision table
| Decision | Prefer the first option when… | Prefer the second option when… | Senior caveat |
|---|---|---|---|
| Versioned URL vs purge | Content is immutable and references can change. | Stable URL must reflect mutable content promptly. | Prefer versioning for assets; purge mutable objects carefully to avoid fill storms. |
| Direct origin vs origin shield | Low PoP count/miss volume and lowest miss latency matter. | Origin protection and cross-PoP reuse dominate. | Shield is a concentration point; deploy capacity/health and possibly multiple shields. |
| Cache personalized response vs bypass | Variants are bounded and authorization/keying can be proven safe. | Privacy/cardinality/risk outweighs hit benefit. | Fragment or cache public subresources instead of whole private pages. |
| Single CDN vs multi-CDN | Operational simplicity and one provider meet risk/performance goals. | Provider, regional, or peering resilience justifies duplicated operations. | Failover must be tested with cold caches and origin capacity. |
| Edge compute vs origin logic | Latency-sensitive lightweight policy close to users adds value. | Transactional state, rich dependencies, or consistent runtime control is needed. | Keep authoritative invariants at origin and version edge/origin contracts. |
| Serve stale vs error | Availability and known bounded staleness are acceptable. | Freshness/security correctness dominates. | Use per-content-class stale limits and expose age/status. |
Quantitative reasoning
Failure modes and production signals
| Failure mode | What users see | Likely cause | Mitigation / design response | Useful signals |
|---|---|---|---|---|
| Global cache leak | Private content served publicly | Wrong cache key/control or stripped auth | Emergency purge/bypass, isolate rule, rotate data if needed, synthetic privacy tests | Cache-status by auth, user mismatch, config audit |
| Origin overload | Edge 5xx/timeouts after purge/cold start | Miss storm, shield failure, low hit ratio | Collapse, stale serve, rate-limit fills, scale origin, rollback purge | Origin fetch RPS/bytes, shield hit, concurrent fills |
| PoP/ISP degradation | Only region/carrier users slow/fail | Peering/routing/capacity issue | Steer to alternate PoP/CDN, engage provider, adjust anycast/DNS | Latency/errors by PoP/ASN/address family |
| Stale content beyond policy | Old asset/API persists | TTL/key mismatch, purge miss, revalidation failure | Version key, verify purge, fix validators, cap stale policy | Age, cache key debug, purge propagation, validator results |
| Direct-origin bypass | DDoS or unauthorized traffic reaches origin | Origin publicly reachable without edge authentication | Private access/mTLS/signed headers, firewall, rotate origin | Direct connection attempts, source IP, auth failures |
| Edge config blast radius | Global outage immediately after rule deploy | Unstaged WAF/cache/compute change | Canary PoPs/percent, automated tests, versioned config, instant rollback | Config version by request, block/cache reason, synthetic probes |
Senior-level lenses
Treat edge config like production code
Store declaratively, review, test against captured traffic, canary by geography and percentage, and attach a version to logs. Global propagation makes tiny mistakes high-blast-radius. Keep an out-of-band rollback path that does not depend on the failing rule.
Origin capacity is based on miss scenarios
Design for ordinary misses, a cold region/CDN, purge of a hot object, shield loss, and multi-CDN failover. The origin may need admission and stale behavior because provisioning for all-user traffic can be uneconomic.
Cache authorization deliberately
Signed URLs/cookies grant access to cacheable bytes, but revocation and sharing semantics must be defined. Very short signatures reduce misuse but lower cache reuse if the token enters the cache key. Commonly authenticate at edge and remove token from the content key after policy verification.
Separate content identity from location
Immutable content-addressed or versioned URLs let any CDN/origin serve the same bytes and simplify multi-CDN migration. Mutable vanity URLs can redirect or reference a version, preserving product ergonomics without sacrificing cache safety.
Edge observability needs sampling strategy
Full logs at trillions of requests are costly. Retain security/audit events, sample successes, aggregate metrics by PoP/ASN/cache status, and support targeted debug tokens. Preserve correlation to origin fills and user reports.
CDN does not solve data locality
It accelerates reads and connection paths, but dynamic writes still depend on authoritative services and data placement. An edge can accept/queue a command only if semantics, authentication, and regional consistency are designed explicitly.
Interview question ladder
What does a CDN do on a cache miss?
Show strong-answer signals
Routes to upper tier/origin, fetches according to policy, may collapse concurrent requests, stores response if cacheable, and returns it.
Why are versioned asset URLs useful?
Show strong-answer signals
Immutable long caching without purge; deploy new content at a new URL, old references remain correct, lifecycle later removes it.
What is byte hit ratio?
Show strong-answer signals
Fraction of delivered bytes served from cache, often more relevant to origin bandwidth than request-count hit ratio.
What is an origin shield?
Show strong-answer signals
Upper-tier cache between edge PoPs and origin, reducing duplicate fills/connections; adds concentration and miss-hop trade-off.
How do signed URLs work with caching?
Show strong-answer signals
Edge validates time-limited signature/claims, then maps authorized request to content cache key; define token sharing, expiry, revocation, and whether token is excluded from key.
How would you purge a hot object safely?
Show strong-answer signals
Prefer versioning; otherwise soft purge/stale revalidation, request collapse, shield, origin capacity/admission, staged rollout, and monitor fill.
Design CDN delivery for a subscription video service.
Show strong-answer signals
Segmented/range media, object storage origin, immutable renditions, signed cookies/URLs, DRM/license separate, multi-tier cache, origin auth, regional rights, logs/egress, purge for takedown.
A CDN returns another user’s API response. Walk through incident response and prevention.
Show strong-answer signals
Bypass/purge, identify key/rule and affected scope, preserve evidence/notify, rotate sensitive tokens if needed, fix private/cache-control/Vary, synthetic multi-user tests, staged config.
How would you implement multi-CDN failover?
Show strong-answer signals
Portable content/origin auth, traffic manager, consistent cert/DNS/cache keys, dual logging/purge, warm baseline, origin capacity for cold failover, health thresholds/hold-down, regular game days.
When should logic run at the edge?
Show strong-answer signals
Auth/routing/redirect/A-B/light transform where latency/offload matters; avoid strong transactional invariants and heavy dependencies. Discuss limits, versioning, security, observability, fallback.
Design global cache invalidation for legal takedowns with a 60-second objective.
Show strong-answer signals
Content ID→all URL/variant tags, authenticated purge to all CDNs/tiers, denylist checked at edge, origin block, verification probes, audit, retries/escalation, offline clients and backup policy.
Reduce origin egress cost by 50% without materially increasing staleness.
Show strong-answer signals
Measure byte misses by object/path/PoP, increase immutable versioning, normalize keys, tiered cache/shield, range optimization, preposition hot content, revalidation, compression, multi-CDN economics; validate freshness SLO.
Design drills
Design global delivery for 5 GiB installers during launch spikes. Include immutable versions, checksum/signature, ranges/resume, multi-CDN, origin shield, and regional restrictions.
What the interviewer is testing
Large-object byte economics, integrity, cold launch, and provider resilience.
Design CDN behavior for public articles, personalized home page, comments, breaking-news updates, and subscriber-only media. Define cache keys, fragments, stale policy, purge, and auth.
What the interviewer is testing
Mixed public/private caching and freshness by content class.
One CDN provider has elevated latency in two ISPs while health checks remain green. Design detection, traffic steering, and safe failover to a colder second CDN.
What the interviewer is testing
User-vantage observability, capacity-aware failover, and avoiding origin collapse.
Common weak answers and how to improve them
“A CDN caches static content.”
Show the stronger answer
Also discuss global proxying, TLS, routing, dynamic acceleration, security, edge compute, and origin protection.
“Purge the cache on deployment.”
Show the stronger answer
Prefer immutable versioning; model propagation and miss storm for mutable purges.
“Use a high TTL for performance.”
Show the stronger answer
Set freshness from product semantics and use validators/versioning; high TTL can prolong errors or revoked content.
“Multi-CDN removes CDN outages.”
Show the stronger answer
It adds configuration drift, cold-cache/origin load, steering, cert/log/purge differences, and must be exercised.
“The origin is hidden behind the CDN.”
Show the stronger answer
Enforce that technically with private/mTLS/signed access and monitor direct attempts.