CDN Interview Questions for Senior Engineers (2026)

Content Delivery Networks are a critical infrastructure component that most senior engineers interact with daily, yet few understand deeply. In interviews at companies like Cloudflare, Akamai, AWS, and any company operating at scale, CDN questions test your understanding of caching, distributed systems, and performance optimization.

CDN questions appear in system design interviews when designing any user-facing system — from video streaming platforms to social media feeds. They also appear in infrastructure and platform engineering interviews where you are expected to make CDN configuration decisions that affect latency, cost, and reliability.

This guide covers the most common CDN interview questions with structured answer frameworks. Each answer goes beyond textbook definitions to cover real-world considerations that distinguish senior engineers. For foundational networking concepts, see our networking interview questions.

For a broader preparation strategy, consult our system design interview guide.

Questions

1. Explain how a CDN works and why it improves performance.

What the interviewer is really asking: Can you explain CDN architecture beyond "it caches content closer to users"?

Answer framework:

A CDN is a geographically distributed network of proxy servers (edge servers or Points of Presence — PoPs) that cache and serve content from locations close to end users.

How it works:

1. DNS routing: When a user requests static.example.com, DNS resolves to the CDN's nameservers. The CDN's DNS uses the client's resolver IP (or EDNS Client Subnet) to determine the nearest PoP and returns its IP.

2. Cache check: The edge server checks if the requested content is in its local cache. Cache keys typically include the URL, query parameters, and relevant headers (Vary header).

3. Cache hit: If cached and not expired (based on TTL from Cache-Control or Expires headers), the edge server responds directly. Latency is minimal — just the user-to-edge RTT.

4. Cache miss: If not cached, the edge server fetches from the origin server (or a mid-tier cache/shield). The response is cached for future requests and returned to the user.

Why it improves performance:

• Reduced latency: Content served from a server 50ms away instead of 200ms away. For a page with 50 resources, this saves 7.5 seconds of cumulative latency.
• Reduced origin load: Popular content is served from edge caches, reducing origin server traffic by 80-95%.
• TCP optimization: CDN edges terminate TLS close to users (1-RTT TLS 1.3 handshake at 20ms vs 200ms to origin). Many CDNs maintain persistent, optimized TCP connections to origins.
• Protocol optimization: CDNs implement HTTP/2, HTTP/3 (QUIC), Brotli compression, and image optimization at the edge.
• DDoS absorption: Distributed edge capacity absorbs volumetric attacks before they reach origin infrastructure.

Architecture layers:

• Edge PoPs: Closest to users. Cache the most popular content. Hundreds of locations globally.
• Regional shields: Mid-tier caches that aggregate cache misses from multiple edge PoPs. Reduces origin load and improves cache hit ratio.
• Origin: The source of truth. Only receives cache misses that pass through shield.

For a deeper understanding of CDN architecture, see how CDNs work.

Follow-up questions:

• How does a CDN decide which PoP to route a user to?
• What is the difference between a push CDN and a pull CDN?
• How do CDNs handle dynamic content?

2. What are the different cache invalidation strategies, and what are their trade-offs?

What the interviewer is really asking: Do you understand the hardest problem in CDN management — keeping cached content fresh?

Answer framework:

Cache invalidation is famously one of the two hard problems in computer science. For CDNs, it is especially challenging because invalidation must propagate to hundreds of edge locations worldwide.

Strategies:

1. TTL-based expiration: Set Cache-Control: max-age=3600. Content automatically expires after the TTL. Simple but imprecise — content may be stale for up to TTL duration, or you may re-fetch content that has not changed.

2. Purge/Invalidation API: Explicitly invalidate specific URLs or URL patterns. Most CDNs support instant purge (Cloudflare: <1 second global, Fastly: ~150ms). Use for: critical updates (pricing changes, security patches), content corrections.

3. Cache busting with versioned URLs: Embed a version or hash in the URL: /app.a1b2c3d4.js. Change the reference when content changes. The old version remains cached (harmless) and the new version is a guaranteed cache miss. Best for static assets in build pipelines.

4. Stale-while-revalidate: Cache-Control: max-age=60, stale-while-revalidate=300. Serve stale content immediately while asynchronously revalidating with origin. Provides instant response times while keeping content relatively fresh.

5. Conditional requests (ETag/Last-Modified): Cache sends If-None-Match or If-Modified-Since to origin. Origin responds with 304 Not Modified (no body) if unchanged. Reduces bandwidth but still requires an origin round trip.

6. Surrogate keys/tags: Assign tags to cached objects. Purge by tag to invalidate all related content at once. For example, tag all product page assets with product-123 and purge when the product updates. Supported by Fastly (Surrogate-Key) and Cloudflare (Cache-Tag).

Trade-offs:

• TTL too short: more origin load, higher latency for cache misses.
• TTL too long: users see stale content.
• Purge APIs: operational complexity, potential for accidental mass purges.
• Versioned URLs: requires build system integration, does not work for HTML pages (since the HTML references must also change).

The best approach combines versioned URLs for static assets (JS, CSS, images) with short TTLs + stale-while-revalidate for HTML pages + surrogate key purging for content changes.

Follow-up questions:

• How would you handle cache invalidation for a social media feed that updates frequently?
• What happens if a purge request fails to reach some edge servers?
• How do you handle cache invalidation across multiple CDN providers?

3. How do CDNs handle dynamic content and personalized responses?

What the interviewer is really asking: Do you know CDNs beyond static file serving?

Answer framework:

Modern CDNs do far more than cache static files. They handle dynamic content through several techniques:

Edge computing:

• Cloudflare Workers, AWS Lambda@Edge, Fastly Compute@Edge allow running custom code at edge locations.
• Use cases: A/B testing (route users to different variants), authentication (validate JWTs at the edge), personalization (modify responses based on geolocation or cookies), API gateway logic.
• Code runs in lightweight isolates (V8 isolates for Cloudflare Workers) with sub-millisecond cold start.

Dynamic content caching strategies:

1. Vary header: Cache different versions based on headers. Vary: Accept-Encoding caches gzip and brotli versions separately. Vary: Accept-Language caches per language. Danger: Vary: Cookie creates a cache entry per unique cookie value, effectively defeating caching.

2. Edge Side Includes (ESI): The page is split into fragments. Static fragments (header, footer) are cached. Dynamic fragments (user name, cart count) are fetched from origin and assembled at the edge. Reduces origin load while maintaining personalization.

3. Cache key customization: Include specific cookie values or headers in the cache key. Cache the page per country or per logged-in/logged-out state rather than per user.

4. Stale content + client-side hydration: Serve a cached generic page, then use JavaScript to fetch personalized content from an API. Best time-to-first-byte with progressive enhancement.

Dynamic content acceleration (without caching):

• Persistent origin connections: CDN maintains warm TCP/TLS connections to origin, eliminating handshake latency.
• Route optimization: CDN uses its private backbone network instead of public Internet routing. Cloudflare Argo and AWS Global Accelerator reduce latency by 30-40%.
• Protocol optimization: HTTP/2 multiplexing between edge and origin, connection coalescing.
• Request collapsing: Multiple simultaneous cache misses for the same URL are collapsed into a single origin request.

For designing systems that leverage CDN capabilities, see our system design interview guide and cloud architecture questions.

Follow-up questions:

• What are the limitations of edge computing compared to server-side rendering?
• How does request collapsing work and when can it cause problems?
• How would you design a CDN strategy for a multi-tenant SaaS application?

4. What is cache stampede (thundering herd) and how do you prevent it?

What the interviewer is really asking: Have you dealt with cache-related production issues at scale?

Answer framework:

A cache stampede occurs when a cached entry expires and multiple concurrent requests simultaneously experience a cache miss, all hitting the origin server at once. For popular content, this can mean thousands of origin requests in milliseconds.

Why it is dangerous:

• A single URL receiving 10K requests/second with a 1-second cache gap means 10K simultaneous origin requests.
• Origin server may become overloaded, causing cascading failures.
• Worse during cold starts: new CDN PoPs or after mass invalidation have empty caches.

Prevention strategies:

1. Request collapsing (coalescing): When a cache miss occurs, the first request fetches from origin. Subsequent requests for the same URL wait for the first request's response rather than making additional origin requests. Most CDNs support this natively.

2. Stale-while-revalidate: Serve the stale cached version immediately while one background request updates the cache. Users get instant responses with slightly stale data. Cache-Control: max-age=60, stale-while-revalidate=3600.

3. Probabilistic early expiration: Each request has a small random probability of triggering a cache refresh before actual expiration. The probability increases as the TTL approaches zero. This spreads refresh load over time.

4. Cache locking: Only one request per cache key can fetch from origin at a time. Others wait or receive stale content. Nginx's proxy_cache_lock implements this.

5. Background refresh: A separate process refreshes popular cache entries before they expire, ensuring they are never truly cold. Works well for known popular content but not for long-tail.

6. Stale-if-error: Cache-Control: stale-if-error=86400. If the origin is down, serve stale content (up to 24 hours old) instead of an error. Acts as a safety net during origin outages.

The best production approach combines request collapsing + stale-while-revalidate + stale-if-error for maximum resilience.

Follow-up questions:

• How does request collapsing interact with personalized cache keys?
• What is the trade-off between stale-while-revalidate and immediate consistency?
• How would you handle a cache stampede for a flash sale page?

5. How do you design a multi-CDN strategy and when is it appropriate?

What the interviewer is really asking: Can you think about CDN architecture at a strategic level, not just as a configuration?

Answer framework:

A multi-CDN strategy uses two or more CDN providers simultaneously to improve reliability, performance, and cost.

When it is appropriate:

• Traffic exceeding 10+ Gbps where a single provider's capacity is a risk.
• Global presence where different CDNs have stronger coverage in different regions.
• High availability requirements where a single CDN outage is unacceptable.
• Cost optimization through competitive pricing and traffic steering.
• Regulatory requirements for data sovereignty in specific regions.

Architecture patterns:

1. Active-active with DNS steering: Use a traffic management DNS service (NS1, Cloudflare Load Balancing, Route 53) to distribute traffic across CDNs based on performance, geography, or cost. Real-time performance monitoring (RUM data, synthetic tests) informs routing decisions.

2. Active-passive failover: Primary CDN serves all traffic. Health checks detect failures and automatically switch DNS to the secondary CDN. Simpler but the secondary CDN cache is cold during failover.

3. Geographic split: CDN A for North America and Europe, CDN B for Asia-Pacific. Each CDN covers the regions where it has the strongest PoP density.

4. Content-type split: CDN A for static assets (optimized for caching), CDN B for video streaming (optimized for large file delivery), edge computing platform for dynamic content.

Challenges:

• Cache consistency: Purge requests must go to all CDN providers. Different purge APIs, different propagation times.
• Configuration drift: Maintaining identical caching rules, security policies, and edge logic across providers.
• Observability: Aggregating logs and metrics from multiple providers into a unified view.
• SSL certificate management: Each CDN needs valid TLS certificates for your domains.
• Cost complexity: Different pricing models (bandwidth tiers, request pricing, commit discounts) make cost comparison difficult.

Decision framework:

• If uptime SLA > 99.99%: multi-CDN is likely necessary.
• If traffic > 50 Gbps: multi-CDN provides cost leverage and capacity safety.
• If global audience: geographic CDN split often provides better performance than any single provider.
• If traffic < 5 Gbps and availability requirements < 99.9%: single CDN is simpler and often sufficient.

For more on designing high-availability architectures, see our cloud architecture interview questions and distributed systems guide.

Follow-up questions:

• How would you handle cache invalidation across three CDN providers?
• What metrics would you use to dynamically route traffic between CDNs?
• How do you handle the cold cache problem when failing over to a secondary CDN?

6. Explain CDN cache key design and its impact on cache hit ratio.

What the interviewer is really asking: Do you understand the nuances of caching beyond simple URL matching?

Answer framework:

The cache key determines which cached response serves a particular request. A poorly designed cache key either serves wrong content (key too broad) or defeats caching entirely (key too specific).

Default cache key components:

• Scheme (http/https)
• Host header
• URL path
• Query string (all parameters)

Cache key optimization strategies:

1. Query parameter filtering: Only include relevant query parameters in the cache key. If utm_source and fbclid are tracking parameters that don't affect content, exclude them. This can dramatically improve hit ratio — a single page with 50 different tracking parameters would otherwise create 50 separate cache entries.

2. Query parameter ordering: Normalize parameter order so ?a=1&b=2 and ?b=2&a=1 are the same cache key.

3. Device-based keys: Include a device class (mobile/desktop/tablet) rather than the full User-Agent string. Vary: User-Agent would create thousands of cache entries for the same content.

4. Geographic keys: Include country or region when content varies by location (pricing, language). Keep granularity appropriate — per-country is usually sufficient, per-city defeats caching.

5. Cookie-based keys: Include specific cookie values, not the entire Cookie header. Cache per session type (logged-in vs anonymous) rather than per session ID.

6. Accept-Encoding: Always include to serve correct compressed variants. Most CDNs handle this automatically.

Measuring cache hit ratio:

• Target: 80-95% for static assets, 50-80% for semi-dynamic content.
• Analyze cache status headers (CF-Cache-Status, X-Cache) in access logs.
• Identify top cache misses and investigate — often caused by unnecessary cache key variation.

Common mistakes:

• Including session cookies in cache keys (creates per-user caching — essentially no caching).
• Not normalizing URLs (trailing slashes, case sensitivity).
• Caching error responses (5xx) with normal TTLs.
• Using Vary: * which disables caching entirely.*

Follow-up questions:

• How would you debug a low cache hit ratio for a specific URL pattern?
• What is the impact of A/B testing on cache hit ratios?
• How do CDNs handle the Vary header and what are its limitations?

7. How does CDN security work, including DDoS protection and WAF?

What the interviewer is really asking: Do you understand CDNs as security infrastructure, not just performance infrastructure?

Answer framework:

Modern CDNs are as much about security as performance. They sit in front of origin servers, creating a natural chokepoint for security enforcement.

DDoS protection layers:

1. Network-layer (L3/L4): Anycast routing distributes volumetric attacks across hundreds of PoPs. Each PoP absorbs a fraction of the total traffic. Major CDNs can absorb attacks exceeding 10 Tbps. BGP-based scrubbing centers filter malicious traffic patterns.

2. Transport-layer: SYN flood protection using SYN cookies (respond without allocating state until the handshake completes). Connection rate limiting per source IP.

3. Application-layer (L7): HTTP flood detection using behavioral analysis, JavaScript challenges (proof-of-work), CAPTCHA challenges, and machine learning models that distinguish bots from humans based on request patterns, TLS fingerprints, and browser capabilities.

Web Application Firewall (WAF):

• Rule-based filtering: OWASP Core Rule Set blocks common attacks (SQL injection, XSS, command injection, path traversal).
• Custom rules: Block specific patterns relevant to your application.
• Rate limiting: Limit requests per source IP/session/API key per time window.
• Bot management: Distinguish between good bots (search engines), bad bots (scrapers, credential stuffers), and humans.
• Managed rules: CDN provider maintains rules for zero-day vulnerabilities (e.g., Log4Shell rules deployed within hours of disclosure).

Origin protection:

• Origin IP hiding: CDN proxies all traffic; origin IP is never exposed.
• Origin authentication: CDN adds a secret header or uses mutual TLS to verify requests came through the CDN, not directly to origin.
• IP allowlisting: Origin firewall only accepts connections from CDN IP ranges.

SSL/TLS security:

• Free automated certificate management (Let's Encrypt integration).
• TLS 1.3 enforcement at the edge.
• HSTS, OCSP stapling, certificate transparency monitoring.

For more on application security, see our security interview questions and OAuth/authentication questions.

Follow-up questions:

• How would you protect against a sophisticated L7 DDoS that mimics legitimate traffic?
• What is the trade-off between WAF strictness and false positives?
• How do you handle a situation where the CDN itself is rate-limiting legitimate traffic?

8. Explain the concept of edge computing and how it differs from traditional CDN caching.

What the interviewer is really asking: Do you understand where CDN technology is heading and how it changes application architecture?

Answer framework:

Traditional CDN caching stores and serves pre-computed content. Edge computing allows running custom application logic at CDN edge locations, moving computation closer to users.

Traditional CDN caching:

• Content is generated at origin and cached at edges.
• Edge servers are passive — they store and forward bytes.
• Logic is limited to cache rules, URL rewrites, and header manipulation.
• Content is either cached or fetched from origin.

Edge computing:

• Custom code runs at edge locations (often on the same servers as the CDN cache).
• Edge functions can generate responses entirely, modify cached responses, make subrequests, and interact with edge key-value stores.
• Sub-millisecond cold starts (V8 isolates for Workers, firecracker VMs for Lambda@Edge).
• Access to edge-native storage: KV stores (Cloudflare KV, Durable Objects), edge databases (D1, Turso).

Use cases where edge computing excels:

1. Authentication and authorization: Validate JWTs, check API keys, enforce rate limits at the edge. Invalid requests never reach origin.
2. A/B testing: Route users to variants based on cookies or random assignment without origin involvement.
3. Geolocation-based responses: Return different content based on user location (pricing, language, compliance).
4. API response transformation: Convert between formats (XML to JSON), filter fields, merge responses from multiple origins.
5. Image optimization: Resize, format-convert (WebP, AVIF), and quality-adjust images on-the-fly at the edge.
6. Bot management: Complex bot detection logic that requires more than simple rules.

Limitations:

• Limited CPU time per request (typically 10-50ms for free tiers, more for paid).
• Limited memory (128MB typical).
• No access to traditional databases without network calls (edge databases are emerging).
• Cold start considerations for infrequently accessed regions.
• Debugging and observability challenges compared to centralized servers.

Edge computing is relevant for serverless architecture discussions and cloud architecture design.

Follow-up questions:

• When would you choose edge computing over a traditional server-side rendered approach?
• How do Cloudflare Workers compare to AWS Lambda@Edge in architecture and limitations?
• What data consistency challenges arise when using edge key-value stores?

9. How do CDNs handle video streaming at scale?

What the interviewer is really asking: Can you explain CDN behavior for the most bandwidth-intensive use case?

Answer framework:

Video streaming is the dominant use case for CDN bandwidth — Netflix alone accounts for roughly 15% of global Internet traffic. CDN architecture for video differs significantly from static asset caching.

Streaming protocols:

• HLS (HTTP Live Streaming): Apple's protocol. Video is split into small segments (2-10 seconds each) with a manifest file (.m3u8) listing available quality levels and segment URLs. Most widely supported.
• DASH (Dynamic Adaptive Streaming over HTTP): MPEG standard. Similar to HLS with segments and a manifest (.mpd). More flexible codec support.
• Both use standard HTTP, making them CDN-friendly — each segment is a regular HTTP resource that can be cached.

Adaptive Bitrate Streaming (ABR):

• Video is encoded at multiple quality levels (360p, 720p, 1080p, 4K).
• The player monitors available bandwidth and buffer level.
• It switches quality levels mid-stream by requesting segments from different quality playlists.
• The CDN serves whatever quality the client requests — quality decisions are client-side.

CDN optimization for video:

1. Segment caching: Each segment is cached independently. Popular content (live events, trending shows) achieves very high cache hit ratios. Long-tail content (old shows) may have lower hit ratios.

2. Predictive pre-fetching: CDN edges pre-fetch the next few segments from origin before clients request them, reducing latency for sequential playback.

3. Origin shielding: Critical for video. Without a shield tier, 200 edge PoPs with a cache miss each would send 200 requests to origin for the same segment. A shield tier reduces this to 1.

4. Byte-range request handling: Players may request partial segments using HTTP Range headers (seeking). CDNs must handle these efficiently without fetching the full segment from origin.

5. Live streaming: Segments are generated in real-time. TTLs must be very short (segment duration). CDN edges must fetch new segments as soon as they are available. Latency target: 2-10 seconds for standard live, <1 second for ultra-low-latency.

Scale considerations:

• A single 4K stream at 25 Mbps means 10,000 concurrent viewers = 250 Gbps. For a major live event with 10M viewers, you need 250 Tbps of edge capacity.
• Storage: A 2-hour movie at 5 quality levels ≈ 15GB. A catalog of 10,000 titles = 150TB.

For system design practice, see our video streaming system design guide.

Follow-up questions:

• How does live streaming CDN caching differ from VOD caching?
• What is the startup latency optimization for video players and how does the CDN contribute?
• How do DRM systems interact with CDN caching?

10. What metrics do you use to evaluate CDN performance?

What the interviewer is really asking: Can you measure CDN effectiveness quantitatively and identify optimization opportunities?

Answer framework:

Cache performance metrics:

• Cache hit ratio (CHR): Percentage of requests served from cache. Target: 85-95% for static, 50-80% for mixed. Measure at both edge and shield tiers.
• Byte hit ratio: Similar but weighted by response size. More representative of bandwidth savings.
• Origin offload: Percentage reduction in origin requests and bandwidth compared to no CDN.

Latency metrics:

• Time to First Byte (TTFB): Time from request to first byte of response. Should be under 50ms for cache hits at nearby edges.
• Cache hit TTFB vs cache miss TTFB: The difference reveals CDN value. A 10x difference is common.
• DNS resolution time: CDN DNS should resolve in under 20ms for most users.
• TLS handshake time: With TLS 1.3, under 30ms to nearby edges.

Availability metrics:

• Edge availability: Percentage of requests that receive a non-error response from the edge (regardless of origin health).
• Origin shield effectiveness: How often the shield satisfies edge requests without going to origin.
• Error rate by type: 5xx from origin vs 5xx from CDN vs 4xx from client.

Real User Monitoring (RUM):

• Largest Contentful Paint (LCP): Core Web Vital that CDN directly impacts.
• First Contentful Paint (FCP): How quickly the first content renders.
• Cumulative Layout Shift (CLS): Can be affected by image dimension handling.

Operational metrics:

• Purge propagation time: How quickly invalidation reaches all edges.
• Origin request rate: Trend over time — should decrease as CHR improves.
• Bandwidth cost per GB: Varies by region and CDN provider.

Follow-up questions:

• How would you set up a dashboard to monitor CDN health?
• What would you investigate if cache hit ratio suddenly dropped 20%?
• How do you compare CDN performance across providers for a multi-CDN strategy?

11. How do CDNs handle HTTPS and TLS termination?

What the interviewer is really asking: Do you understand the security model of CDN TLS and its implications?

Answer framework:

TLS termination at the CDN edge means the CDN decrypts HTTPS traffic, inspects/caches/modifies it, and optionally re-encrypts for the origin connection.

TLS modes:

1. Full (strict): Edge terminates client TLS, re-encrypts to origin with certificate validation. Most secure. The origin must have a valid, trusted certificate.

2. Full (flexible): Edge terminates client TLS, re-encrypts to origin without certificate validation. Origin can use a self-signed certificate. Less secure — vulnerable to MITM between CDN and origin.

3. Flexible: Client-to-edge is HTTPS, edge-to-origin is HTTP (unencrypted). Content travels unencrypted between CDN and origin. Only appropriate if origin is on the same physical network.

4. End-to-end with client certificates: CDN passes client TLS certificates to origin for mutual TLS authentication.

Certificate management:

• CDN-managed certificates: CDN provisions and renews certificates automatically (using Let's Encrypt or their own CA). Simplest option.
• Custom certificates: Upload your own certificate and private key to the CDN. Required for EV certificates or specific organizational requirements.
• Keyless SSL: CDN never has your private key. The TLS handshake is split — the CDN handles the bulk of TLS but delegates the private key operation to a key server you control. Used by organizations with strict key management policies.

Performance optimization:

• OCSP stapling at the edge eliminates client-side certificate revocation checks.
• Session resumption and TLS 1.3 0-RTT reduce subsequent connection setup.
• HTTP/3 (QUIC) at the edge combines transport and TLS handshake.

Security considerations:

• The CDN can see all decrypted traffic. This is a trust and compliance consideration.
• For PCI-DSS or HIPAA data, ensure the CDN provider is certified.
• Certificate transparency logs make all CDN-issued certificates publicly visible.

Follow-up questions:

• What are the security implications of giving your TLS private key to a CDN provider?
• How does Keyless SSL work technically?
• What happens to cached content when you rotate TLS certificates?

12. Explain how anycast routing works and why CDNs use it.

What the interviewer is really asking: Do you understand the network-layer mechanism that makes CDNs work globally?

Answer framework:

Anycast is a network addressing method where the same IP address is announced from multiple locations. Routers direct traffic to the nearest (topologically closest) instance based on BGP routing.

How it works:

• Multiple CDN PoPs announce the same IP address via BGP.
• Internet routers see multiple paths to the same IP and select the shortest (fewest AS hops, lowest latency).
• Users are automatically routed to their nearest PoP without any application-layer logic.

Why CDNs use anycast:

1. Automatic geographic routing: No DNS-based routing logic needed. The network itself routes users to the nearest server.
2. DDoS resilience: Attack traffic is distributed across all PoPs announcing the address. No single location receives the full attack volume.
3. Simple DNS: Return a single IP address in DNS. No complex geo-DNS configuration.
4. Failover: If a PoP goes down, it withdraws its BGP announcement. Traffic automatically reroutes to the next nearest PoP within minutes (BGP convergence time).

Anycast vs unicast DNS-based routing:

• Anycast: routing at the network layer, automatic, ~1 minute failover (BGP convergence), works for both TCP and UDP.
• DNS-based: routing at the application layer, requires DNS infrastructure, TTL-dependent failover (seconds to minutes), more control over routing decisions.
• Most CDNs use both: anycast for DNS queries (DNS servers are anycast) and DNS-based routing for content (returning different unicast IPs per region).

Anycast challenges:

• BGP convergence during failover can cause brief connection resets for established TCP connections.
• In-flight TCP connections may be routed to a different PoP during route changes, causing connection resets.
• Anycast granularity is at the BGP routing level, which may not align with actual geographic proximity.

Follow-up questions:

• How do CDNs handle TCP connection persistence with anycast?
• What happens to active connections when a PoP fails in an anycast setup?
• How does Cloudflare's anycast architecture differ from Akamai's DNS-based routing?

13. How would you design a CDN from scratch for a global e-commerce platform?

What the interviewer is really asking: Can you make CDN architecture decisions for a specific business context?

Answer framework:

Requirements analysis:

• Product pages with images (cacheable but frequently updated)
• User sessions and personalized recommendations (dynamic)
• Checkout flow (cannot cache, must be secure)
• Global audience with traffic spikes (flash sales, holidays)
• Sub-second page loads for conversion optimization

Architecture decisions:

1. Static assets strategy: Version all JS, CSS, and product images with content hashes. Set Cache-Control: public, max-age=31536000, immutable. These never need invalidation — new versions get new URLs. Use Brotli compression at the edge.

2. Product page strategy: Cache the HTML shell with max-age=60, stale-while-revalidate=300. Use surrogate keys (Product-ID: 12345) for instant purge when product data changes. Personalized elements (recommendations, cart count) loaded via client-side API calls.

3. API caching: Cache product catalog API responses with short TTLs (30-60s). Cache search results by normalized query. Never cache cart, checkout, or user account APIs.

4. Image optimization: Use CDN image transformation to serve WebP/AVIF with appropriate dimensions per device. Lazy-load below-fold images. Pre-cache hero images for top products.

5. Geographic considerations: Origin servers in US-East and EU-West. CDN shield in each origin region. Edge PoPs worldwide. Price localization served via edge function using geo-IP.

6. Flash sale preparation: Pre-warm CDN caches for sale products. Increase origin capacity. Use waiting room (Cloudflare Waiting Room) to queue excess traffic during spikes.

7. Security: WAF rules for bot protection (inventory scrapers), rate limiting on checkout APIs, DDoS protection at the edge, origin IP hiding.

Monitoring:

• Cache hit ratio per content type (target: 95% static, 70% pages, 0% checkout)
• TTFB by region (target: <100ms cache hit, <500ms cache miss)
• Core Web Vitals (LCP <2.5s)
• Origin load and error rate

For more on system design, see our system design interview guide and e-commerce system design.

Follow-up questions:

• How would you handle cache invalidation when a product goes out of stock?
• What is your strategy for handling bots that scrape product pricing?
• How would you architect the CDN for a global flash sale with 10x normal traffic?

14. What is origin shielding and when should you use it?

What the interviewer is really asking: Do you understand multi-tier CDN caching architecture?

Answer framework:

Origin shielding adds a mid-tier cache layer between CDN edge PoPs and the origin server. Without shielding, each of the CDN's hundreds of edge PoPs independently fetches from origin on a cache miss. With shielding, edge misses go to a single shield PoP, which fetches from origin only if the shield also has a miss.

Benefits:

1. Reduced origin load: Without shield, N edge PoPs × M concurrent cache misses = N×M origin requests. With shield, it reduces to approximately M origin requests (assuming shield has a warm cache).

2. Higher effective cache hit ratio: Shield aggregates cache demand from all edges, increasing the popularity (and thus cache lifetime) of every object.

3. Connection efficiency: Instead of hundreds of edge-to-origin connections, you have a few shield-to-origin connections. Enables persistent, optimized connections.

4. Reduced bandwidth cost: Origin egress is reduced by shield hit ratio (often 60-80%).

When to use it:

• Origin has limited capacity or is expensive to scale.
• Content catalog is large (many unique URLs) and edge cache hit ratio is low.
• Origin is far from most users — shield should be close to origin for fast misses.
• You want to protect origin during traffic spikes or cache invalidation events.

When NOT to use it:

• Content is real-time and stale data is unacceptable (the shield adds one more cache layer and potential staleness).
• You have very few edge PoPs (the benefit scales with PoP count).
• Origin is extremely fast and cheap — the added latency of the shield hop may not be worthwhile.

Shield placement:

• Place the shield PoP close to the origin server to minimize shield-to-origin latency.
• For multi-region origins, use one shield per origin region.
• Some CDNs offer multi-tier shields (edge → regional shield → origin shield → origin).

For more on caching architectures, see our how caching works guide and Redis interview questions.

Follow-up questions:

• How does request collapsing at the shield tier work differently from the edge tier?
• What happens if the shield PoP itself goes down?
• How would you size and place shield PoPs for a multi-region origin architecture?

15. How do you handle cache warming and pre-fetching strategies?

What the interviewer is really asking: Can you proactively manage CDN performance rather than just reacting to cache misses?

Answer framework:

Cache warming is the proactive population of CDN caches before user requests arrive. Pre-fetching is the speculative loading of content that users are likely to request next.

Cache warming strategies:

1. Synthetic requests: Script that sends requests to every edge PoP for critical content. Can target specific PoPs using CDN-specific headers or by connecting to specific PoP IP addresses. Best for: after deployments, before marketing campaigns, before flash sales.

2. Origin push: Push content to CDN edges proactively rather than waiting for pull on cache miss. Limited CDN support — more common with push CDNs or custom CDN infrastructure.

3. Crawl-based warming: Run a web crawler that follows links on your site through the CDN. Populates caches for discoverable content. Simple but does not warm API endpoints.

4. Traffic replay: Capture a sample of production request logs and replay them against the CDN after a cache clear or PoP addition. Ensures the new cache is warm with actual traffic patterns.

Pre-fetching strategies:

1. HTTP Link preload headers: Link: </next-page.js>; rel=preload. CDN can push or prioritize these resources.

2. Predictive pre-fetching: Based on user navigation patterns, pre-fetch likely next pages. For example, if 70% of users viewing product A also view product B, pre-fetch B's assets.

3. Manifest-based pre-fetching: Application provides a manifest of related resources. CDN or service worker pre-fetches them during idle time.

4. Edge-side pre-fetching: CDN edge parses HTML responses and pre-fetches referenced resources from origin, warming the cache before the browser requests them.

Considerations:

• Pre-fetching increases origin load and bandwidth costs for content that may never be viewed.
• Over-aggressive pre-fetching can pollute the cache, evicting popular content for speculative content.
• Measure pre-fetch hit ratio — if pre-fetched content is rarely subsequently requested, reduce pre-fetching.

Follow-up questions:

• How would you warm CDN caches across 200 PoPs for a major product launch?
• What is the cost-benefit analysis of pre-fetching?
• How does service worker caching interact with CDN caching?

Common Mistakes

1. Treating CDN as just a static file server. Modern CDNs handle dynamic content, edge computing, security, and observability. Understanding the full capability set is essential for senior-level discussions.

2. Setting overly aggressive TTLs without invalidation strategy. A 1-year TTL is useless if you cannot invalidate efficiently. Combine long TTLs with versioned URLs or surrogate key purging.

3. Ignoring cache key design. Default cache keys often include unnecessary variation (tracking parameters, session cookies) that destroy cache hit ratios. Always audit and optimize cache keys.

4. Not considering the origin impact of cache misses. Cache stampedes, cold starts, and mass invalidation can overwhelm origins. Design defensively with shields, request collapsing, and stale-while-revalidate.

5. Overlooking security capabilities. CDN WAF, DDoS protection, and bot management are as important as caching. Include these in your architecture discussions.

6. Failing to measure CDN performance. Without cache hit ratio monitoring, RUM data, and origin load tracking, you cannot optimize or justify CDN investment.

How to Prepare

Week 1: CDN Fundamentals

• Understand pull vs push CDN models.
• Study cache headers: Cache-Control, Vary, ETag, Last-Modified.
• Learn cache key design principles and common pitfalls.

Week 2: CDN Architecture

• Study multi-tier caching: edge → shield → origin.
• Understand anycast vs DNS-based routing.
• Learn about CDN provider architectures (Cloudflare, Fastly, Akamai, CloudFront).

Week 3: Advanced Topics

• Edge computing: Cloudflare Workers, Lambda@Edge.
• Video streaming and CDN: HLS, DASH, ABR.
• Security: WAF, DDoS, bot management.

Week 4: Practice

• Design CDN strategies for different application types (e-commerce, media, SaaS).
• Practice cache invalidation scenarios.
• Study CDN-related incident reports.

For comprehensive preparation, see our system design interview guide and explore learning paths.

Related Resources

• System Design Interview Guide — Complete preparation framework
• How CDNs Work — Deep dive into CDN architecture
• Networking Interview Questions — TCP/UDP/DNS fundamentals
• Cloud Architecture Interview Questions — AWS/GCP/Azure patterns
• Video Streaming System Design — Designing for scale
• Distributed Systems Guide — Core distributed concepts
• Security Interview Questions — Application security
• Redis Interview Questions — Caching deep dive
• Start Learning — Structured learning paths
• Pricing — Premium preparation resources