57 CDN Interview Questions and Answers (2026)

A Point of Presence (PoP) is a CDN's physical edge location: a cluster of caching servers placed close to end users (often inside or peered with ISP networks) to serve content with minimal latency. It differs from a traditional data center in purpose, size, and geographic strategy.

• What a PoP is:

  • A geographically distributed node containing edge cache servers, load balancers, and network gear, peered at internet exchanges (IXPs) for short paths to users.

  • There are many (dozens to hundreds), each serving the users nearest to it.

• How it differs from a traditional data center:

  • Purpose: a PoP caches and delivers content close to users; a data center hosts the authoritative application, databases, and compute (the origin).

  • Footprint: PoPs are small and numerous, optimized for proximity; data centers are large, centralized, and fewer.

  • State: PoPs hold mostly ephemeral cached copies; data centers hold the source of truth.

• Goal: by terminating connections and serving cached bytes at the PoP, the CDN cuts round-trip distance, which is the single biggest lever on latency.

A PoP (Point of Presence) is an entire edge location, a cluster of machines in one geographic site, whereas a single edge server is just one caching machine inside that PoP. The distinction matters for capacity, redundancy, and how cache and load balancing behave within a location.

• A PoP is a location, not a box:

  • It contains many edge servers plus local load balancers and network peering, all sharing the same nearby-user advantage.

  • Users are routed to a PoP (via Anycast/DNS); load balancing then picks a server inside it.

• An edge server is one node:

  • It does the actual work: caches objects, terminates TLS, serves or proxies requests.

  • One server failing should not take down the PoP; peers absorb its traffic.

• Practical implication: cache is often sharded/coordinated across servers within a PoP (consistent hashing) so the same object isn't redundantly stored on every machine, improving in-PoP hit ratio.

A CDN (Content Delivery Network) is a globally distributed network of edge servers that cache and serve content close to users, offloading the origin. It primarily solves latency, scalability, origin load, and availability/security problems for modern web apps.

• Latency / proximity: Serving bytes from a nearby PoP cuts round-trip time versus reaching a distant origin, speeding page loads.

• Origin offload and scalability: Cached responses absorb most traffic so origin handles far fewer requests, smoothing traffic spikes and flash crowds.

• Bandwidth cost and throughput: Edge delivery reduces expensive origin egress and improves effective throughput via local caching and optimized routes.

• Availability and resilience: Distributed PoPs and failover keep content reachable even if origin or a region is down; cached content can still serve.

• Security at the edge: Absorbs/mitigates DDoS, provides WAF, TLS termination, and hides the origin behind the edge.

• Best for cacheable/static-ish content (images, JS/CSS, video, API responses); dynamic personalized data benefits less, though dynamic acceleration and edge compute help.

An edge server (part of a PoP) is a CDN cache node placed close to users that serves cached content and proxies misses, while the origin server is the authoritative source that holds and generates the canonical content. The edge exists to shield and accelerate the origin.

• Edge server:

  • Located in distributed PoPs near users; caches copies, terminates TLS, and serves responses with low latency.

  • On a cache miss it fetches from origin (or a parent/shield), stores the result, and serves it.

  • Holds ephemeral copies governed by TTL/cache-control, not the source of truth.

• Origin server:

  • The authoritative backend (app servers, object storage) that produces fresh/dynamic content.

  • Usually centralized and fewer; ideally only sees misses and uncacheable requests.

• Key difference: edge = many, near users, cached and disposable; origin = central, authoritative, the thing the CDN protects.

TTFB is the time from a client sending a request to receiving the first byte of the response: it captures DNS, connection setup, TLS, and the server's processing/queuing delay. A CDN usually lowers TTFB on cache hits by serving from a nearby edge, but can add a hop on misses.

• What TTFB includes: Network round trips (DNS, TCP/QUIC, TLS) plus the time the server takes before the first byte.

• CDN on a cache hit: The edge is physically close, so shorter RTTs and no origin processing mean a much lower TTFB.

• CDN on a cache miss: The edge must fetch from origin, adding a hop; but warm, reused connections and optimized backbone routing often still beat the client going to origin directly.

• Indirect wins: TLS termination at the edge and connection reuse cut handshake overhead even for dynamic responses.

With a pull CDN the edge fetches content from origin on demand the first time it's requested; with a push CDN you proactively upload content to the CDN ahead of time. Pull is the common default; push suits large, infrequently changing assets you want preloaded.

• Pull CDN:

  • First request is a miss that fetches from origin and caches it; subsequent requests are hits until TTL expires.

  • Low maintenance and self-healing, but the first user per edge eats the miss penalty.

  • Best for frequently changing or large catalogs where preloading everything is impractical.

• Push CDN:

  • You upload assets and manage their lifecycle (updates, expiry) yourself.

  • No cold-miss penalty and predictable origin load, but more operational overhead and wasted storage for unrequested files.

  • Best for large, stable files (software downloads, big media) or low-traffic sites where natural cache warming is rare.

Hotlinking is when another website embeds your assets (images, video, files) directly using your URLs, so their visitors load content from your CDN and you pay the bandwidth while they get the benefit. A CDN prevents this by inspecting each request's origin at the edge and rejecting those that don't come from your allowed sites.

• Referer-based protection:

  • The edge checks the Referer header against an allowlist of your domains and blocks (403) requests from foreign sites.

  • Weakness: Referer can be absent or spoofed, so it's a deterrent, not airtight.

• Stronger options:

  • Signed URLs/tokens so embedded links expire and can't be reused elsewhere.

  • CORS and Origin header checks for browser-loaded resources.

• Why the edge is the right place: Blocking happens before any bandwidth or origin cost is incurred, so the theft is stopped at the source of the traffic.

The key CDN metrics measure how much load it absorbs and how fast/reliably it serves users: cache hit ratio, latency, throughput/bandwidth offload, error rate, and origin offload.

• Cache Hit Ratio: Higher ratio means more requests served at the edge and less origin traffic; the core efficiency metric.

• Latency / Time to First Byte: Edge response time, ideally segmented by region and percentile (p50, p95, p99) rather than averages.

• Throughput and bandwidth offload: How many bytes the CDN serves versus the origin: directly tied to origin cost and capacity savings.

• Error rate and availability: Rate of 4xx/5xx and edge-vs-origin errors; helps separate CDN problems from origin problems.

• Origin offload: Percentage of total traffic kept off origin; closely related to CHR but expressed from the origin's protection angle.

The CDN fetches a new version when its cached copy is no longer considered fresh: either the object's TTL has expired, or it's explicitly told to (a purge), at which point it revalidates with or re-fetches from the origin.

• Freshness check on each request: While within TTL (from Cache-Control: max-age / s-maxage or Expires), the edge serves the cached copy with no origin contact.

• On expiry it revalidates, not blindly re-downloads:

  • Sends a conditional request using If-None-Match (with the stored ETag) or If-Modified-Since.

  • Origin replies 304 Not Modified (keep the copy, reset freshness) or 200 with new bytes.

• Explicit triggers: A purge/invalidation marks the object stale immediately, forcing a fetch on the next request.

• A cache miss (never seen, or evicted by LRU) also forces an origin fetch.

The origin uses Cache-Control response headers to declare whether a response may be cached, by whom, and for how long. The CDN reads these directives to decide what to store at the edge and when it goes stale.

• Cacheability directives:

  • public: any cache (including the CDN) may store it.

  • private: only the end user's browser may cache it, not shared CDN caches.

  • no-store: never cache; no-cache: may store but must revalidate before each reuse.

• Lifetime directives:

  • max-age=N: freshness in seconds for any cache.

  • s-maxage=N: overrides max-age specifically for shared caches like the CDN, letting you give the edge a different TTL than the browser.

• Validation companions: ETag / Last-Modified enable cheap 304 revalidation once TTL expires.

• Precedence: Cache-Control wins over the legacy Expires header when both are present.

The 'last mile' is the final network hop between the edge/ISP and the end user's device, while the 'middle mile' is the path between the origin and the CDN edge (across the public internet or the CDN's backbone). CDNs mainly attack the middle mile, since the last mile is largely outside their control.

• Last mile:

  • User to nearest PoP/ISP: limited by the user's connection (Wi-Fi, mobile, broadband) and local congestion.

  • CDNs improve it indirectly by placing PoPs physically close so this hop is as short as possible, but can't fix the user's link itself.

• Middle mile:

  • Edge to origin: long-haul paths prone to congestion, packet loss, and suboptimal BGP routing on the public internet.

  • This is where CDNs add the most value: private backbones, optimized routing, persistent/pooled connections, and tiered caching to shorten or eliminate this trip.

• Why it matters: caching at the edge removes the middle mile entirely on hits, so the only remaining cost is the last mile, which is why proximity-based PoP placement is so important.

A CDN adds value when content is cacheable, geographically dispersed, or benefits from edge proximity; when none of those apply, it adds cost and complexity for little gain.

• Highly personalized or per-request dynamic data: Authenticated dashboards or responses unique per user cache poorly, so you mostly pay for a pass-through hop.

• Single-region, low-latency internal apps: If all users and the origin sit in one region (e.g. an intranet), edge distribution buys little.

• Strict data residency or compliance constraints: Regulations may forbid caching sensitive data (PII, health, financial) on third-party edges.

• Rapidly changing or real-time data: Stock tickers, live game state, and WebSocket streams gain little from caching and may suffer staleness.

• Very low traffic: With few requests, hit ratios stay low and the CDN's fixed cost outweighs the savings.

A CDN trades raw performance and origin offload against added cost, operational complexity, and a new layer of cache/consistency concerns.

• Benefits: Lower latency via edge proximity, reduced origin bandwidth/load, absorbs traffic spikes and DDoS, and offloads TLS.

• Cost: Egress and request pricing add up; for low-traffic sites it can cost more than it saves.

• Cache consistency: Stale content is a real risk; you must manage TTLs, versioned URLs, and purges carefully.

• Operational complexity: New layer to configure, debug, and monitor: cache headers, origin shields, and harder-to-trace bugs across the edge.

• Loss of direct control: You depend on the provider for availability, TLS handling, and visibility into request behavior.

A CDN serves cached copies from the edge so most requests never reach origin; the share it absorbs is the offload ratio, derived from cache hit ratio and bytes served.

• How it reduces load: Cached responses are returned by edges, so origin only sees misses, revalidations, and uncacheable requests.

• Origin shield / tiered caching: A mid-tier cache funnels misses through one point, collapsing duplicate origin fetches further.

• Quantifying offload:

  • Byte hit ratio is the truest measure of bandwidth saved (large files dominate), while request hit ratio reflects load.

  • Offload % = bytes served by edge / total bytes; a 95% byte hit ratio means origin carries only 5% of traffic.

• Request collapsing: Concurrent misses for the same object are coalesced into one origin fetch, protecting against thundering herds.

Yes: even when the response body can't be cached, a CDN can accelerate delivery by optimizing the network path between client and origin. That set of techniques is called Dynamic Site Acceleration (DSA).

• Connection reuse: The edge keeps warm, pooled connections to origin, so each request skips fresh TCP/TLS handshakes.

• TLS termination at the edge: The expensive handshake happens close to the user over a short RTT, not across the whole internet.

• Optimized routing: Traffic rides the provider's private backbone with better paths than the public internet's BGP route.

• Protocol upgrades and tuning: HTTP/2 or HTTP/3, larger congestion windows, and compression at the edge speed transfer of dynamic bytes.

• Micro-caching: Even a 1 second TTL on "dynamic" content can absorb bursts without meaningful staleness.

CDNs transform images at the edge on the first request (resizing, recompressing, converting to modern formats like WebP/AVIF) based on URL parameters and request headers, then cache each variant. This is better than per-request origin work because it scales globally and reuses cached results.

• How it works:

  • Transform directives come from query params or path (e.g. width, quality) and content negotiation via theAcceptheader to pick WebP/AVIF.

  • The edge generates the variant once, caches it keyed by those parameters, and serves it to all later matching requests.

• Why it beats on-the-fly at origin:

  • Origin CPU isn't burned re-encoding the same image repeatedly; the work happens once per variant near the user.

  • Smaller, format-optimized payloads reduce bandwidth and improve load time worldwide.

  • You store one master image instead of pre-generating and maintaining every size/format combination.

• Caveat: Vary on the right dimensions (format, DPR) to avoid cache fragmentation or serving the wrong variant.

Signed URLs and Signed Cookies attach a cryptographically signed token (a policy plus a signature) to a request, and the CDN edge validates that signature before serving content. Because the secret key never leaves you and the CDN, an attacker can't forge or tamper with the token, so only authorized, time-limited requests succeed.

• What's in the signature:

  • A policy stating constraints: expiry time, allowed path/resource, sometimes an IP range.

  • An HMAC or RSA signature over that policy, computed with a private/shared key.

• How validation works at the edge:

  • The CDN recomputes/verifies the signature with its copy of the key and checks the policy (not expired, path matches).

  • Any mismatch or expired token returns 403, so no origin round-trip is needed.

• Typical flow:

  1. User authenticates with your application.

  2. Your app generates a signed URL/cookie using the secret key.

  3. User requests the asset; the edge verifies and serves it.

• Why it's secure:

  • Tokens are short-lived, so a leaked link stops working quickly.

  • Signature can't be altered without the key, so users can't extend expiry or change the path.

A WAF inspects HTTP traffic for application-layer attacks (SQL injection, XSS, path traversal) and blocks malicious requests. At the CDN edge it filters globally and early, before traffic reaches your network; on the application server it's closer to the app and sees fully decrypted, app-specific context but only after traffic has already arrived.

• WAF at the CDN edge:

  • Blocks attacks close to the attacker, so malicious traffic never consumes origin bandwidth or compute.

  • Scales with the CDN's capacity, so it absorbs large L7 attack volumes a single server couldn't.

  • Centrally managed rules apply across all origins behind it.

• WAF on the application server:

  • Has deep, app-specific context (sessions, business logic), so it can write very precise rules.

  • Last line of defense if traffic bypasses the CDN (e.g. direct-to-origin hits).

  • Limited by that server's resources, so it offers no help against volumetric L7 floods.

• Best practice: defense in depth: Use both: edge WAF for scale and early filtering, origin WAF/app validation as a backstop, plus lock the origin to only accept CDN traffic.

Use Signed URLs when you need to protect individual resources or hand out a single link, and Signed Cookies when one authorized session needs access to many files without signing each one. The choice comes down to granularity: per-object vs. per-session.

• Signed URLs:

  • Best for a single file: a download link, a one-off video, an emailed or shared resource.

  • Each URL is self-contained, so it works where cookies can't be set (RESTful clients, direct links).

  • Downside: every asset needs its own signed link, which is unwieldy for many files.

• Signed Cookies:

  • Best for granting access to a group of resources: a whole video library, all assets on a paywalled page.

  • Set once; the browser sends the cookie automatically for all matching paths, so you don't rewrite each URL.

  • Downside: requires a cookie-capable client and you can't easily share a single asset link.

• Rule of thumb: One file or non-browser client, use a Signed URL; many files within one authenticated browser session, use Signed Cookies.

Rate limiting at the edge caps how many requests a client (by IP, token, or other key) can make in a time window, enforced at the CDN's PoPs. It's more effective there than at the origin because excess requests are rejected close to the attacker, across the whole distributed network, before they ever consume origin bandwidth or compute.

• How it works:

  • A counter (token bucket / sliding window) per key tracks request rate; over the threshold returns 429 or blocks.

  • Keys can be IP, API token, header, or a combination for finer control.

• Why the edge wins:

  • Abusive traffic is dropped at the PoP, so the origin never sees it and stays healthy.

  • Edge has the capacity to reject floods that would overwhelm a single origin's limiter.

• The distributed-state caveat: Counters are spread across many PoPs, so a perfectly global count is hard; CDNs use approximate/synced counters, which is fine for abuse control.

• Use cases: Throttling API abuse, brute-force login attempts, scraping, and L7 DDoS.

Bot management is the practice of identifying automated traffic and deciding what to do with it: allow good bots (search crawlers), block or challenge bad ones (scrapers, credential stuffers, scalpers). A CDN does this at the edge using signals from its huge cross-customer traffic visibility, so it can classify and act before requests reach your origin.

• Detection signals:

  • Fingerprinting: TLS/JA3 fingerprints, HTTP header order, and User-Agent consistency reveal automation.

  • Behavioral analysis: request rate, navigation patterns, and impossible mouse/timing behavior.

  • Reputation: IP history and known-bot databases built from network-wide data.

• Mitigation responses:

  • Challenge: CAPTCHA or JavaScript/proof-of-work to weed out non-browsers.

  • Block, rate-limit, or serve alternate content (tarpit) for confirmed bad bots.

  • Allowlist verified good bots by reverse-DNS validation, not just User-Agent.

• Why at the edge: Bots are stopped before consuming origin resources, and the CDN's aggregate visibility makes detection far stronger than any single site could achieve.

Cache Hit Ratio (CHR) is the fraction of requests served from CDN cache rather than the origin, calculated as hits / (hits + misses), usually measured over a time window from edge logs or analytics.

• Definition and measurement:

  • Count requests answered at the edge versus those forwarded to origin; can be measured by request count or by bytes served.

  • Edge logs expose a status field like HIT, MISS, EXPIRED, or STALE to classify each request.

• Reason 1: short or missing TTLs: Low max-age or missing Cache-Control means objects expire fast and constantly revalidate against origin.

• Reason 2: cache key fragmentation: Query strings, cookies, or a Vary on User-Agent split one resource into many cached variants, so each gets few hits.

• Reason 3: non-cacheable responses: Origin sends no-store, Set-Cookie, or error/4xx/5xx statuses that the CDN refuses to cache.

Start from the response itself: confirm the cache status header, then work backward through cache key, cacheability headers, and TTL to find what stopped the hit.

• Step 1: confirm the status: Inspect the CDN's cache header (e.g. X-Cache: MISS or CF-Cache-Status) to distinguish a true MISS from EXPIRED or BYPASS.

• Step 2: check the cache key: Does the URL carry varying query strings, or does config include cookies/headers in the key? A different key is always a miss.

• Step 3: inspect cacheability headers: Look for Cache-Control: no-store, private, a Set-Cookie, or a broad Vary that the origin returned.

• Step 4: check TTL and freshness: A very short max-age or already-expired object forces revalidation; verify Age and Expires.

• Step 5: consider edge topology: A cold/regional POP, recent purge, or low-traffic object simply may not have it cached yet; retry from the same POP.

Cache Hit Ratio (CHR) is the share of requests served from the edge cache instead of origin, hits / (hits + misses); you raise it mainly by making more responses cacheable, normalizing keys, and tuning TTLs.

• Way 1: increase TTLs and enable revalidation: Set longer max-age/s-maxage and use stale-while-revalidate so objects stay servable while refreshing.

• Way 2: normalize the cache key: Strip irrelevant query params (tracking like utm_*), ignore unneeded cookies, and avoid varying on User-Agent to collapse variants.

• Way 3: make more content cacheable: Remove unnecessary Set-Cookie and no-store on static assets, and cache things like API GETs or HTML where safe.

• Bonus: tiered/shielded caching: An origin-shield layer lets edge POPs fill from a parent cache, raising the effective hit ratio for less-popular objects.

Low origin CPU/RAM suggests the bottleneck is in delivery, not compute, so use CDN logs to find where time and errors accumulate: edge latency, origin fetch time, cache misses, or a slow region.

• Separate edge time from origin time: Compare total response time against origin response time in logs; a large gap points at the network path or edge, a small gap with slow origin points at backend latency (DB, locks) the CPU graph hides.

• Check cache status distribution: A flood of MISS means users wait on origin fetches; correlate with low CHR.

• Segment by geography and POP: If one region's latency is high, suspect a degraded POP, peering issue, or distant routing rather than the origin.

• Look at object size and status codes: Large uncompressed payloads, missing gzip/br, or retries/timeouts to origin all slow delivery without taxing origin CPU.

The Vary response header tells caches which request headers make the response different, so the CDN stores a separate cached variant per distinct value of those headers.

• What it does: It effectively adds the named request headers to the cache key: Vary: Accept-Encoding keeps gzip and brotli responses separate.

• Common safe use: Varying on Accept-Encoding or Accept-Language is fine because the value set is small.

• The danger: high-cardinality headers: Vary: User-Agent or Vary: Cookie creates near-unique variants, fragmenting the cache and crushing CHR.

• Vary: *: Tells caches the response is uncacheable/unique per request: avoid unless intended.

A cache key is the unique identifier the CDN uses to store and look up a cached object, by default built from scheme, host, and path; anything extra you add (query strings, headers) multiplies the number of stored variants, called cache fragmentation.

• Default key: Typically https + host + /path; two requests with the same key share one cached object.

• Query strings: If included, ?v=1 and ?v=2 are separate entries; tracking params like utm_source needlessly fragment unless stripped or sorted.

• Headers like User-Agent: Adding User-Agent to the key (or via Vary) creates thousands of variants for the same content, each rarely hit.

• The trade-off: Include only what genuinely changes the response: normalize/whitelist params to keep the key narrow and the hit ratio high.

Negative caching is caching error or not-found responses (e.g. 404, 500, 503) for a short period so the CDN doesn't hammer the origin with repeated requests for content it already knows is unavailable.

• What it caches: Non-200 responses, typically error and redirect status codes, for a deliberately short TTL.

• Why it matters:

  • Origin protection: a viral request for a missing asset, or a brief origin outage, won't trigger a flood of identical requests (a stampede) to the origin.

  • Faster failure: clients get the error from the edge instead of waiting on a slow round trip.

• The key tradeoff is TTL length: Too long and a fixed/published resource keeps returning a stale 404; keep negative TTLs short (seconds) so recovery is quick.

• Origin can control it via Cache-Control on the error response, or the CDN applies a default negative TTL.

Cache key normalization is the process of transforming a request into a canonical cache key so that logically identical requests map to the same cached object. Stripping irrelevant query parameters at the edge prevents needless cache fragmentation and dramatically raises the hit ratio.

• The cache key is what the CDN looks up: By default it often includes the full URL (host + path + query string); every distinct query string becomes a separate cached object.

• Why strip query parameters:

  • Marketing/tracking params like utm_source, fbclid don't change the response body but create thousands of unique keys for the same asset.

  • Each unique key is a separate miss, so the origin gets hit repeatedly for identical content.

• How to normalize:

  • Whitelist only params that genuinely affect the response (e.g. ?page=2), and drop the rest.

  • Also sort params, lowercase the host, and ignore irrelevant headers/cookies to maximize collapsing.

• Caveat: never strip a param the origin actually varies on, or you'll serve the wrong content to users.

Both remove confidence in a cached object, but a hard purge (invalidation) deletes it so the next request must re-fetch from origin, while a soft purge (revalidation) just marks it stale so the CDN can still serve it while it revalidates in the background.

• Hard purge / invalidation:

  • Object is evicted entirely; the next request is a guaranteed miss and blocks on an origin fetch.

  • Guarantees no stale bytes are ever served, but can spike origin load if many users hit the gap (a stampede).

• Soft purge / revalidation:

  • Object is flagged stale but kept; the CDN can serve the stale copy and revalidate against the origin (via ETag) behind the scenes.

  • If the origin returns 304, the old bytes are reused cheaply; only changed content is re-downloaded.

• When to use which:

  • Hard purge for content that must never be served stale (legal, security, wrong/leaked data).

  • Soft purge for routine content updates where a brief stale window is acceptable and origin protection matters.

stale-while-revalidate lets the cache serve a stale copy instantly when the TTL has just expired, while it fetches a fresh version from the origin in the background. The user never waits on the origin, and the cache is updated for the next request.

• How it works:

  • After max-age expires, the object is stale but usable for the stale-while-revalidate window.

  • A request in that window gets the stale response immediately; an async revalidation refreshes the cache out of band.

• Why it beats a plain TTL:

  • With a standard TTL, the first request after expiry blocks on a full origin round trip (a latency cliff for that user).

  • With SWR, expiry refreshes are invisible: latency stays low and origin load smooths out instead of spiking.

• Tradeoff: Users may see slightly stale content for the duration of the window, so size it to your tolerance for staleness.

• Often paired with stale-if-error, which serves stale content when the origin is down.

Expiration (TTL) is the passive, time-based mechanism where an object becomes stale on its own; invalidation (purging) is an active, on-demand command to remove or mark content stale before its TTL ends. Invalidation is far more expensive for a global CDN because it must propagate to every edge node worldwide.

• Expiration (TTL):

  • Driven by max-age/s-maxage; each edge decides locally with no coordination.

  • Cheap and scalable, but you can't react faster than the TTL you set.

• Invalidation (purge):

  • An explicit operation that must reach every PoP holding the object, often thousands of servers across regions.

  • Requires a distributed control-plane fan-out, so it's slower to take full effect and limited in throughput.

• Which is more expensive: Invalidation, by far: global propagation, coordination, and the risk of origin stampedes once everything goes stale at once.

• Practical guidance: prefer good TTLs and versioned URLs (cache-busting filenames) so you rarely need to purge at all.

is a Cache-Control extension (RFC 5861) that lets a CDN serve a cached-but-expired response when the origin returns an error or is unreachable, trading slight staleness for availability.

• What it specifies: e.g. Cache-Control: max-age=600, stale-if-error=86400 means: fresh for 10 min, but if revalidation fails for up to 24h, keep serving the stale copy.

• When the CDN applies it:

  • Triggered when the origin returns 5xx (500, 502, 503, 504) or times out / connection-refuses.

  • Instead of passing the error to the user, the edge returns the last good cached object.

• Why it matters:

  • Decouples user-facing availability from origin health: the CDN acts as a safety net during outages or deploys.

  • Often paired with stale-while-revalidate, which serves stale instantly while refreshing in the background.

• Caveat: Only works if the object is still in cache; a never-cached or fully evicted resource has no stale copy to fall back on.

A flash crowd is absorbed by the CDN's edge serving cached copies to the masses while a small set of consolidated requests reaches the origin, so a million viewers map to only a handful of origin fetches.

• Edge offload via caching: Once an object is cached at a POP, every subsequent local user is served from edge RAM/SSD, never touching the origin.

• Request collapsing / coalescing: If many users request an uncached object simultaneously, the edge sends ONE request to origin and holds the others until it returns, preventing a stampede.

• Tiered / hierarchical caching: Edge POPs pull from a regional 'shield' or parent cache, so origin sees requests from a few shields, not thousands of edges.

• Resilience directives: stale-while-revalidate and stale-if-error keep serving content even while the origin is slow or struggling.

• Key insight: The origin's load scales with the number of unique/uncached objects, not with viewer count, so cacheable content makes spikes nearly free.

You geo-fence by having the edge inspect the user's resolved location and then serve, redirect, or block content per region, all at the POP without round-trips to origin.

• Determine location at the edge: The CDN maps the client IP to country/region and exposes it (e.g. a CloudFront-Viewer-Country header or an edge geo variable).

• Apply policy at the edge:

  • Allow/deny: block or return 451/403 for restricted regions (licensing, compliance).

  • Redirect or rewrite: route EU users to a localized site or language variant.

  • Personalize: run logic in an edge function (Lambda@Edge, Cloudflare Workers) to assemble region-specific responses.

• Keep the cache correct: Add the geo dimension to the cache key (e.g. Vary or include country in the key) so a US user never gets a cached EU response.

• Caveat: IP geolocation isn't perfect and VPNs bypass it; for strict legal geo-fencing add server-side verification.

A cold start is a cache miss: the requested object isn't yet at a given POP, so that user pays a full origin fetch. Cache warming is proactively populating edge caches before real traffic arrives so the first users hit a warm cache.

• Why cold starts happen:

  • Caches are per-POP and per-object: a hit in Tokyo doesn't help London.

  • Also after a TTL expiry, eviction (LRU pressure), or a cache purge/deploy.

• Cost of a cold start: That user gets origin latency; many simultaneous cold misses can stampede the origin (mitigated by request collapsing).

• Cache warming techniques:

  • Pre-fetch: script requests to key objects across target POPs before a launch or big event.

  • Use the CDN's push/preload API to seed content into edges.

  • Tiered caching reduces cold-start pain: an edge miss is served by a warm regional shield instead of the far origin.

• When it matters most: Product launches, live events, or large software releases where the first wave of users would otherwise all miss.

Terminating TLS at the edge means the expensive handshake happens close to the user (a few ms away) instead of across the long path to origin, cutting the round-trips that dominate connection setup latency.

• Handshake RTTs are local: A TLS handshake costs multiple round-trips; doing it over a 5ms edge link instead of a 100ms origin link is dramatically faster.

• Session/connection reuse:

  • The edge keeps warm, already-established TLS connections to the origin (or a fast internal backbone), so user connections don't each pay origin setup cost.

  • Supports TLS session resumption and 0-RTT for returning clients at the edge.

• Offloads crypto from origin: Encryption/decryption CPU is handled by the edge fleet, freeing origin resources.

• Enables modern protocols: The edge can offer HTTP/2 and HTTP/3 to users even if the origin doesn't, plus optimized cipher suites.

• Caveat: Traffic is decrypted at the edge, so for end-to-end security the CDN must re-encrypt to the origin (TLS to origin), not send plaintext.

With Keep-Alive the edge maintains a pool of persistent, already-warmed TCP/TLS connections to the origin and reuses them across many user requests, avoiding a fresh handshake on every fetch.

• What it avoids per request: A new connection needs a TCP handshake plus a TLS handshake (several RTTs); reuse skips both for subsequent requests.

• Connection pooling at the edge: The POP keeps a set of long-lived origin connections shared across thousands of users, so origin fetches start instantly.

• Avoids TCP slow-start penalty: A warm connection already has a large congestion window, so transfers run at full speed instead of ramping up each time.

• Controlled by headers/config: Connection: keep-alive and keep-alive timeout/max-requests tune how long and how often connections are reused.

• Caveat: The origin must allow enough concurrent keep-alive connections and not close them too aggressively, or the edge falls back to costly new connections.

Compressing and minifying at the edge cuts bytes over the wire (faster downloads, lower bandwidth bills) but costs CPU per response and can hurt if misapplied to already-compressed or tiny payloads.

• Wins:

  • Smaller transfer sizes mean faster first render and less egress cost, especially for text (HTML/CSS/JS/JSON).

  • Doing it at the edge offloads CPU from origin and applies broadly across cached objects.

• Costs and risks:

  • CPU overhead per request, particularly high Brotli levels (10/11); often only worth it for cacheable static assets.

  • Compressing already-compressed content (images, video, .zip) wastes CPU and can inflate size.

  • Tiny responses can grow due to compression headers/overhead; set a minimum size threshold.

  • Aggressive minification can break fragile JS/CSS or strip needed whitespace in <pre> content.

• Caching interaction: Must vary on Accept-Encoding so a Brotli client doesn't get a Gzip-only cache entry (or store multiple encodings).

• Practical split: Brotli (static, high level) for cached assets; Gzip or low-level Brotli for dynamic responses where CPU per request matters.

Brotli and Gzip are lossless compression algorithms applied to text-based HTTP responses; doing it at the edge is usually better because the CDN compresses once for a cacheable object and serves it close to many users, sparing origin CPU and bandwidth.

• What they are:

  • Gzip: widely supported DEFLATE-based compression; fast, good ratio.

  • Brotli: newer, typically 15-25% smaller than Gzip on text at comparable speed; selected via Accept-Encoding: br.

• Why at the edge:

  • Compress once, reuse: a cached object is compressed at the edge and served to many clients without re-running on origin.

  • Saves origin CPU and the origin-to-edge bandwidth stays manageable while the heavy fan-out happens near users.

  • The edge can pick the best encoding per client based on its Accept-Encoding header.

• Caveat: For non-cacheable dynamic responses the edge must compress per request, so it's CPU work either way; choose the level accordingly.

Edge Compute runs your code (small JS/Wasm functions) directly on CDN POPs, so the network that used to only cache and forward static bytes can now generate, transform, and route responses dynamically close to the user.

• What it is:

  • Lightweight functions (e.g. Cloudflare Workers, Lambda@Edge) on isolates/Wasm runtimes with fast cold starts.

  • They run during the request lifecycle: on viewer request, origin request, or response.

• How it changes the CDN model:

  • From passive cache to programmable layer: the edge can personalize, A/B test, rewrite, authenticate, and assemble responses.

  • Dynamic content can be served with edge proximity, not just static files.

  • Logic that once required an origin round trip now resolves at the POP.

• Constraints that keep it 'edge': Tight CPU/memory/time limits, limited runtime APIs, and usually no local state (rely on edge KV stores or origin).