Global CDN — Interview Perspective

Avoid assuming 'cache everything.' Open by clarifying what content classes are in scope — static assets, APIs, video, private/personalized content — and what freshness and purge guarantees are required. This tests whether the candidate treats scoping as part of the design, not a formality. See Problem Definition.

• What content are we serving? — Tests whether the candidate distinguishes workload classes instead of treating all traffic identically.
• Do we support static files, APIs, video, and private content? — Tests whether personalized/auth-sensitive content is called out as a bypass case early, not discovered later.
• What freshness guarantees are required? — Tests whether the candidate connects freshness requirements to TTL/revalidation/purge choices made later.
• Do we need explicit purge? — Tests whether the candidate treats purge as a deliberate scope decision, not an assumed feature.

State it explicitly rather than leaving it implied: authoritative DNS internals, BGP protocol implementation, certificate-authority internals, and video transcoding are adjacent systems, not part of this design. This tests scope discipline. See Scope.

• Why exclude video transcoding specifically? — Tests whether the candidate can articulate the CDN boundary — delivery of already-packaged content, not producing it.
• Would you exclude certificate-authority internals the same way? — Tests consistency in applying the same scoping logic across different adjacent systems.

Work from an assumed DAU and request/object-size figures, label every number as an illustrative assumption, and show peak vs average with an explicit peak multiplier. This tests comfort with order-of-magnitude reasoning under stated assumptions. See Capacity Estimation.

• Why does average object size matter? — Tests whether the candidate connects object size to both bandwidth math and cache tiering decisions.
• What changes when video dominates traffic? — Tests recognition that byte hit ratio and admission policy become more important than request hit ratio alone.
• How does a 95% hit ratio change origin capacity? — Tests the multiplicative-offload reasoning: hit ratio compounds across edge and shield tiers.

Request hit ratio is the fraction of requests served from cache; byte hit ratio is the fraction of bytes served from cache — a cache can look strong on one and weak on the other, especially with large-object or video traffic. This tests precision about metrics rather than treating 'hit ratio' as one number. See Capacity Estimation.

• Which one matters more for origin cost? — Tests whether the candidate connects byte hit ratio to actual origin bandwidth bills, not just request counts.

Client reaches a nearby edge, the edge computes a cache key, checks freshness, and serves from memory or SSD without contacting origin. This tests whether the candidate can narrate the fast path precisely, including the freshness check step most candidates skip. See Cache Hit Lifecycle.

• What if the object is present but expired? — Tests whether the candidate recognizes this routes to revalidation, not a plain hit or a cold miss.

A miss walks edge → shield → origin, with the shield performing request coalescing so the 10,000 simultaneous misses collapse into one upstream fetch rather than 10,000. This tests recognition of the thundering-herd risk and the mechanism that prevents it. See Cache Miss Lifecycle and Origin Shielding.

• Where does request coalescing actually happen? — Tests whether the candidate places this at the shield layer specifically, not vaguely 'somewhere in the CDN.'
• Why add an origin shield instead of letting every edge fetch directly? — Tests understanding that shielding is a correctness/stability feature, not just an optimization.

Freshness is tracked via max-age/Expires and the accumulated Age. Once expired, the edge doesn't necessarily fetch fresh bytes immediately — it can send a conditional request (If-None-Match/If-Modified-Since) and get back a cheap 304 Not Modified if nothing changed. This tests whether the candidate knows revalidation exists as a distinct path from hit and cold miss. See HTTP Cache Freshness and Revalidation.

• What is an ETag, concretely? — Tests whether the candidate can explain it as an opaque representation identifier, not just 'a hash.'
• How does 304 Not Modified actually help? — Tests understanding that it avoids re-transferring the body while still confirming freshness.
• What is stale-while-revalidate? — Tests whether the candidate distinguishes it from both hit and revalidation-blocking.
• When is serving stale content unsafe? — Tests policy judgment — auth, financial, and security-sensitive content should not casually serve stale.

The key determines which requests can share a response — typically host, normalized path, and a deliberately selected set of query parameters and headers. Including every query parameter blindly destroys hit ratio; ignoring parameters that actually change the response causes wrong content to be served. This tests whether the candidate treats key design as a real decision, not an implementation detail. See Cache Key Design and Normalization.

• What about cookies? — Tests recognition that identity-bearing cookies must not silently become part of a publicly shared cache key.
• What does Vary do, conceptually? — Tests whether the candidate can explain representation variance without over-claiming HTTP-spec precision.
• How can bad cache-key design leak personalized content? — Tests the direct link between key design mistakes and privacy/security incidents.
• How can an attacker destroy hit ratio using key cardinality? — Tests awareness of cache-key-explosion as an actual attack surface, not just an efficiency concern.

Tier by heat: RAM for the hottest small objects, SSD for a larger warm set, promoting/demoting based on observed access. A one-time huge object can bypass admission entirely — being fetched once doesn't earn a spot that would otherwise hold many popular smaller objects. This tests the admission-vs-eviction distinction specifically. See Cache Eviction and Admission Policies.

• What is admission versus eviction? — Tests whether the candidate can name these as two separate policy decisions rather than one.
• Why does byte hit ratio matter here? — Tests the connection between admission policy and overall origin bandwidth savings, not just request counts.

DNS-based geo-routing and Anycast both exist, often together — DNS gives coarse policy control, Anycast gives BGP-based path selection that can shift traffic away when a route is withdrawn, at a speed that depends on failure detection and routing propagation. No: Anycast selects a network/policy-preferred path, which is often nearby but is not a distance guarantee, because BGP doesn't understand geography or application latency directly. This tests whether the candidate avoids the common 'Anycast = nearest' myth. See Anycast Routing and Anycast vs DNS-based Routing.

• What does BGP actually optimize? — Tests whether the candidate can say 'network/policy path preference,' not 'shortest physical distance.'
• What happens when a PoP fails? — Tests recognition that route withdrawal takes effect over a convergence window, not instantly and uniformly.
• Why might DNS and Anycast both exist in the same architecture? — Tests understanding that these are complementary layers, not a strict either/or choice.

Direct edge-to-origin fetches mean origin load scales with the number of edge locations, which real origins were rarely built to survive. A shield collapses many misses into few origin fetches. If the shield itself fails, moving traffic to a fallback path gradually — with bounded concurrency and coalescing preserved — avoids a second incident caused by the recovery itself. This tests understanding of failover stampede risk specifically. See Origin Shielding and Regional Cache / Shield Failure.

• How do you choose among multiple possible origins? — Tests awareness of origin selection inputs — health, priority, region, request type — beyond a single hardcoded origin.
• How do you prevent users from bypassing the CDN and hitting origin directly? — Tests knowledge of origin protection mechanisms — private connectivity, mTLS, allowlisting.

No — purge is inherently an asynchronous, eventually-consistent fan-out: a durable intent is recorded, then propagated to regions and applied at individual edges, each of which can acknowledge at a different stage. This tests whether the candidate resists promising instantaneous global deletion. See Cache Invalidation.

• How do you know every PoP applied it? — Tests the three-level acknowledgement distinction: accepted durably, delivered to region, applied at edge.
• What happens to stragglers? — Tests whether the candidate has an actual answer beyond 'it eventually finishes' — straggler tracking and operator visibility.
• Why are fingerprinted assets preferable when possible? — Tests recognition that versioned URLs sidestep the hardest part of purge entirely for static content.

They live in a durable control-plane store, but no — the data plane must not depend on live central lookups per request. Every edge runs from a versioned local snapshot, refreshed asynchronously. This tests the data-plane/control-plane separation specifically. See Final Architecture and Configuration and Certificate Distribution.

• What if the control plane goes down? — Tests whether the candidate says existing traffic keeps working from local snapshots, while new changes queue.
• How do you safely roll out a new cache rule globally? — Tests knowledge of the validate → version → canary → staged rollout → fleet convergence sequence.
• How do you roll it back? — Tests whether rollback is understood as a fast, first-class operation, not an afterthought.

Video is delivered as a manifest plus segmented renditions, each segment cacheable independently; range requests matter for partial delivery. Huge segments compete for the same cache capacity as everything else, which is exactly why admission policy — not just eviction — matters: a huge one-time object shouldn't displace a large volume of smaller hot content. This tests connecting video specifics back to the general admission/eviction framework. See Video and Large-Object Delivery.

• Why segment video at all? — Tests understanding that small cacheable segments route and cache better than one giant file.
• Why does sustained throughput matter in addition to time-to-first-byte? — Tests recognition that playback can start fast and still rebuffer if sustained delivery isn't handled too.

Origin protection combines hiding the origin from direct public access (authenticated paths, private connectivity) with the cache itself never contacting origin more than necessary. Cache poisoning happens when a cache-key or normalization mistake lets one response get served to users it was never meant for — often traced back to a Vary or auth-handling error. This tests connecting the security question back to cache-key correctness, not treating it as a separate topic. See Edge Security and Cache Poisoning.

• How does the CDN help with DDoS? — Tests distinguishing volumetric, connection-exhaustion, and application-layer attacks rather than treating 'DDoS protection' as one thing.
• Why is WAF placement at the edge useful? — Tests recognition that filtering close to ingress protects both shield and origin resources.

Because the config-rollout pipeline is staged and versioned, this shouldn't reach every region instantly — canary PoPs and health gates should catch it first. If it does get through, recovery is a fast rollback to the last known-good version, not a scramble to hand-author a fix. This tests whether the candidate designed for this failure mode proactively, not just reactively. See Bad Global Configuration Rollout.

• A tenant suddenly consumes 30% of a PoP's capacity — what now? — Tests per-tenant quota/admission-control knowledge, per Noisy Neighbor / Tenant Hotspot.
• Certificate rollout failed in one region — what's the blast radius? — Tests whether the candidate scopes this correctly as regional/hostname-specific rather than fleet-wide.
• Routing sends a whole continent to a distant PoP — how do you detect that? — Tests knowledge that routing health should be measured from external vantage points, not just internal telemetry.

No — at that scale, a single origin plus a basic pull cache (or even a managed CDN product) is entirely sufficient; most of this design (shield tiers, Anycast, elaborate purge fan-out) is earned by scale, not assumed from day one. This tests whether the candidate can right-size architecture instead of reproducing a planet-scale diagram regardless of the stated load. See Scaling.

• When would you introduce a shield? — Tests recognition that this is earned by origin load and long-tail traffic patterns, not a default from the start.
• When is DNS routing sufficient, and when does Anycast become worth the complexity? — Tests staged reasoning about routing maturity rather than jumping straight to the most sophisticated option.