Design a CDN

A multi-tenant CDN for 30 M customer domains: 300 PoPs, 50 M requests a second served mostly from cache, and global purges in seconds.

Last updated 2026-10-26. Difficulty: hard. Patterns: cdn, anycast, tiered-cache, cache-invalidation, multi-tenancy. Reported at Cloudflare, Akamai, Amazon, Google, Microsoft, Netflix.

Functional requirements

• Route every user to a nearby PoP. One of 300 points of presence, usually within 20 to 30 ms. Anycast by default: every PoP announces the same addresses and the internet’s routing picks the nearest. A PoP that fails or fills up stops receiving traffic within a minute.
• Serve cacheable content from cache. Images, scripts, video segments and API responses with cache headers, honouring the origin’s Cache-Control, s-maxage and Vary, with per-customer rules that override them (TTLs, which query parameters matter).
• Fetch misses with minimal origin load. A popular object should be fetched from a customer’s origin about once per expiry, not once per PoP or per server: a cache hierarchy plus request coalescing. Uncacheable requests are proxied on pooled connections.
• Purge globally within seconds. By URL, by tag (surrogate key) or everything for a domain. A hard purge deletes; a soft purge marks content stale so it is revalidated. The API says when every PoP has applied it.
• HTTPS on customers’ own domains. Terminate TLS at the edge for 30 M domains: certificates issued and renewed automatically or uploaded by the customer, chosen per handshake by SNI. TLS 1.3, HTTP/2 and HTTP/3.
• Self-serve configuration. Origins, cache rules, redirects, WAF and rate-limit settings through an API and a dashboard. A customer’s own change is live worldwide in seconds; changes that affect every customer roll out in stages.
• Absorb traffic spikes and attacks. Flash crowds and DDoS at layers 3, 4 and 7, from multi-terabit floods to HTTP floods. An attack on one customer must not slow down the others sharing the same servers.
• Keep serving when the origin fails. Serve the last good copy (stale-if-error) while the origin is down, fail over to a backup origin where one is configured, and do not knock the origin over again as it recovers.
• Out of scope. Edge compute (Workers-style functions), image and video transformation, the content of WAF rules, analytics and billing pipelines, hosting customers’ DNS zones, and the design of the private backbone between PoPs.

Non-functional requirements

• Scale (50 M req/s · 40 Tbit/s at peak). Across 300 PoPs and 30 M customer domains, on 100 Tbit/s of capacity. The headroom is deliberate: it is what absorbs a lost PoP or a multi-terabit attack on top of the daily peak.
• Latency of a hit (RTT to PoP p50 < 25 ms · < 5 ms inside). Being close is the product. TLS 1.3 adds one round trip (none on resumption), so everything inside the PoP on a hit, from the config lookup to reading the object, must cost a few milliseconds at most.
• Origin offload (≥ 95 % of cacheable requests). This drives the hardest trade-off in the design. 300 PoPs put users close but split every object’s demand 300 ways, so PoPs that each miss on their own multiply origin load. Hashing inside the PoP, an upper tier and coalescing exist to win back the hit ratio that proximity costs.
• Purge propagation (p50 < 500 ms · p99 < 5 s). A stale price or a legal takedown that keeps serving is a correctness bug for the customer. A purge must never be lost: every PoP acknowledges it, and a PoP that cannot catch up stops serving.
• Availability (99.99 % per domain · no global outage). A PoP, server or disk failure is routine and must be invisible beyond a reconnect. A network-wide outage must be structurally hard, which mostly means controlling how changes are deployed.
• Change safety (blast radius: one customer or a few PoPs). The largest CDN outages on record came from a change pushed everywhere at once, not from hardware. A customer’s own change may be fast; anything that touches every customer is staged with health gates and a global stop.
• Tenant isolation (one domain cannot degrade another). 30 M customers share every server, cache and address range. Per-domain limits on requests, origin fetches and CPU, and cache keys scoped by zone, so one customer’s content can never be served for another’s.
• Security of keys and content (keys encrypted at rest · nothing private cached). Customers’ private keys sit on thousands of servers in other people’s buildings, so they are encrypted at rest and decrypted only inside the TLS process. Responses marked private, or carrying Set-Cookie, never enter a shared cache.

Back-of-envelope estimates

• Requests per PoP at peak: ~170 k/s average. 50 M req/s ÷ 300 PoPs ≈ 167 k/s. PoPs are far from equal: the largest 30, in big metros and at exchange points, carry about half the traffic at ~830 k/s each, and the smallest serve a few thousand. Capacity is planned per PoP, for its own peak plus a failed neighbour’s.
• Peak egress: ~40 Tbit/s. 50 M req/s × ~100 KB average response = 5 TB/s = 40 Tbit/s. Requests are mostly small (scripts, API responses, thumbnails); bytes are mostly large (video segments, images). Against 100 Tbit/s of capacity that is 2.5× headroom, which is what absorbs a lost PoP or a multi-terabit attack on top of peak.
• Cache servers: ~5 000 (~17 per PoP). For small objects TLS and HTTP processing, not the network card, is the limit: about 20 k req/s per server at full CPU. 50 M ÷ 20 k = 2 500 servers at 100 %; run at 50 % so a PoP can take a failed neighbour’s load or an attack: ~5 000 servers, each doing ~10 k req/s and ~8 Gbit/s at peak. The average PoP has ~17; the largest have 100 or more.
• Distinct content in one PoP: ~400 TB, not ~20 TB. A 20-server PoP with 20 TB of SSD per server. If every server caches whatever its own connections ask for, all of them hold roughly the same popular set and the PoP stores about one server’s worth, ~20 TB, while a long-tail object is fetched upstream once per server that sees it. Hashing each cache key to one owner server makes the disks add up: 20 × 20 TB = 400 TB. That 20× is the case for hashing inside the PoP.
• Cacheable requests reaching origins: ~1.1 M/s (97.5 % offload). 90 % of 50 M req/s are for cacheable objects: 45 M/s. Edges hit 90 %, so 4.5 M/s go to upper tiers, which hit 75 % of those: ~1.1 M/s reach origins. Without the tier origins would see 4.5 M/s, 4× more, and the extra misses are exactly the long tail an origin is worst at serving. The other 5 M/s (uncacheable) pass through the tier on pooled connections.
• Purge fan-out: ~600 k PoP deliveries/s. At a peak of 2 k purge requests a second (publish hooks from customers’ CMSs are most of them), each must reach all 300 PoPs: 2 k × 300 = 600 k deliveries a second. Batching every 20 ms per PoP turns that into 300 × 50 = 15 k messages a second on the relays, and inside a PoP a tag purge touches only the objects its index lists. Purge is a fan-out problem, not a storage one.
• Configuration on every server: ~60 GB. 30 M domains × ~2 KB of compiled rules (origins, cache rules, WAF and rate-limit settings) = 60 GB, kept on every server’s SSD in a memory-mapped store so a lookup is a local read. Changes run at ~1 k/s at peak. Small enough to replicate everywhere, which is what removes any remote call from the request path.
• Certificate renewals: ~250 k/day. About 15 M certificates cover the 30 M domains (wildcards and multi-name certificates share), ~75 GB with chains. On 90-day certificates renewed at day 60: 15 M ÷ 60 ≈ 250 k a day, ~3/s, spread with jitter to stay inside CA rate limits. The CA/Browser Forum has voted to cut maximum lifetimes to 47 days by 2029, which roughly doubles this, so issuance must be fully automatic.

Components

• End users (browsers · apps · bots): Browsers and apps loading 30 M customers’ websites, plus crawlers and attackers that look the same at first. They never know a CDN is involved: they resolve the customer’s hostname and connect to whatever address comes back. Their network’s routing, not their geography, decides which PoP they reach.
• Steering DNS (anycast · latency maps): Authoritative DNS for the names customers CNAME to us. For most networks it returns the shared anycast address and lets BGP pick the PoP; for networks the mapper has flagged, it returns a regional address group chosen from measured latency, health and load. It is itself served over anycast, so it is as hard to take down as the edge.
• L4 load balancer (ECMP · XDP · Maglev hash): Runs on every server in the PoP: routers spread packets with ECMP, and an XDP program hashes the 5-tuple to the server that owns the connection, with a connection table so a routing change does not break flows in progress. It is also the first DDoS filter, dropping fingerprinted attack packets before the kernel spends anything on them. Replies go straight back to the user (direct server return).
• Edge proxy (TLS · HTTP/3 · rules): Terminates TLS and HTTP on whichever server received the connection, reads the domain’s config locally, applies WAF and rate limits, computes the cache key and fetches the object from the PoP server that owns that key. Any server can serve any customer, so the PoP is one pool of CPU. Per-zone limits keep one customer’s flood from using another’s share.
• PoP cache (RAM + SSD · owner by hash): Each object lives on one owner server per PoP, chosen by rendezvous hashing of the cache key, so the PoP’s disks add up instead of all holding the same objects; only hot keys are copied to every server. The hottest objects sit in RAM and warm ones on SSD, written only on a second request so one-hit wonders do not churn the disk. The owner coalesces concurrent misses into one upstream fetch and keeps a tag index for purges.
• Upper tier (shield) (per-origin · coalescing): About 15 large PoPs whose caches sit between the edges and customer origins. Each origin is assigned the upper-tier PoP nearest to it, plus a backup, so misses from all 300 edges converge on one cache that coalesces them into a single origin fetch. It keeps warm connections to origins, caps concurrency per origin and serves stale copies when an origin fails.
• Customer origin (their servers · buckets): The customer’s own web servers, API or object-storage bucket: the source of truth for content and for its Cache-Control and Surrogate-Key headers. Usually sized for a small fraction of the traffic the CDN serves. It should accept requests only from our address ranges or authenticated pulls, or attackers will simply go around the edge.
• Certificate store (per PoP · keys encrypted): Every customer certificate and its private key, about 15 M certificates and 75 GB, replicated to each PoP with keys encrypted at rest. A server loads a certificate on the first handshake that names it (SNI) and keeps hot ones in memory, so a cold name costs a local read, not a call across an ocean. OCSP staples travel with the certificate where the CA still offers OCSP.
• Edge config store (versioned KV · every server): A memory-mapped local copy of every domain’s compiled configuration, about 60 GB, on every server, applied from a replicated log in sequence order. Request-time lookups never leave the machine. Each server keeps the previous version of every entry and reports the version it runs, which makes instant rollback and “is it live everywhere?” possible.
• Purge bus (relays · sequence · acks): A durable, sequenced purge log fanned out by about ten regional relays over persistent streams to an agent in every PoP, edges and upper tiers alike, batched every 20 ms. PoPs acknowledge the highest sequence they have applied, so the control plane knows when a purge is complete and a reconnecting PoP replays exactly what it missed.
• Traffic mapper (RTT · health · load): Aggregates sampled TCP round-trip times per client network and PoP, plus each PoP’s health and load, into maps of which PoP serves each network best. Where anycast routes a network badly or a PoP runs hot, it changes DNS answers for steerable names and drives BGP changes such as withdrawing one prefix group at one PoP. It is how routing problems become visible at all.
• Config distributor (replicated log · two lanes): Compiles each change, tests it against the real proxy build in a sandbox, appends it to a replicated log and streams it to every server’s config store and every PoP’s certificate store. A customer’s change takes a fast lane, live worldwide in seconds and reverted automatically if that zone’s errors rise; changes every customer runs take a staged lane (canary, 1 %, 10 %, 100 %) with health gates between stages.
• Control plane API (config DB · versioned): The customer-facing API and dashboard for domains, origins, rules, certificates and purges. Backed by a strongly consistent database in which every change to a zone gets the next version number, so the state of every server can be named exactly. It is never on the request path: if it is down, the edge keeps serving with the config it has.
• Certificate manager (ACME · renewals · OCSP): Issues certificates for new domains through ACME with at least two CAs, proving control with HTTP-01 tokens served by our own edge or DNS-01 records, and renews every certificate at two thirds of its life, about 250 k a day. Fetches OCSP responses for CAs that still provide them so the edge can staple them, and alerts on any certificate within 14 days of expiry.
• Certificate authorities (ACME · two or more): Public CAs that sign certificates after validating control of the domain. They have their own rate limits and outages, so issuance is spread across more than one and retried with backoff. Lifetimes are shrinking (47-day maximums by 2029), which makes renewal volume a design input.

User flows

1. Load an image: hit or miss. The main read path. Anycast picks the PoP, any server terminates TLS, one owner server per object answers from RAM or SSD, and a miss climbs to the origin’s shield before it reaches the origin. Every hop is chosen by a different hash, and each one exists to keep the hit ratio up.
   1. The browser resolves the customer’s hostname and gets a shared anycast address. The customer’s img.shop.com is a CNAME to a name we serve. For most networks the answer is the same anycast address everywhere with a 5-minute TTL, because BGP will do the steering; only networks the mapper has flagged get a regional address group instead. DNS is not on the per-request path after the first lookup.
   2. The connection lands at the nearest PoP and is spread across its servers. BGP delivers the SYN or QUIC Initial to the topologically nearest PoP, about 20 ms away for most users. Routers spread packets with ECMP, and the XDP balancer on each server hashes the 5-tuple Maglev-style and keeps a connection table, so every packet of the connection reaches the same server even if ECMP reshuffles. Replies leave directly from that server, so the balancer only carries the small inbound half.
   3. That server terminates TLS with the certificate for the requested name. The ClientHello’s SNI says which of 30 M domains this is. The certificate and key come from an in-memory LRU, or on first use from the PoP’s encrypted certificate store in about a millisecond, after which the server keeps it hot. TLS 1.3 costs one round trip and none on resumption, and ticket keys are shared across the fleet so resumption works at any PoP.
   4. The proxy reads the domain’s configuration and computes the cache key. Config is a local read from the memory-mapped store on the same server, at a known version: origin, cache rules, WAF and rate limits. The cache key is the zone, host, normalised path and the query parameters the rules keep, sorted, plus one normalised value per header the response varies on (Accept-Encoding becomes br, gzip or identity). Tracking parameters such as utm_* are dropped.
   5. The proxy hashes the key to the server in the PoP that owns it and asks that server. Rendezvous hashing over the PoP’s healthy servers puts each object on exactly one of the 40, so the PoP holds 40 servers’ worth of distinct content instead of one. The owner answers from RAM for hot objects or from SSD (~100 µs) for warm ones, and the hop inside the PoP costs well under a millisecond. Keys above ~1 k req/s in the PoP are copied to every server and served locally.
   6. On a miss, the owner holds every concurrent request for the key on one fetch from the origin’s shield. Forty browsers asking for a new image in the same second become one request out of the PoP, because they all hash to one owner and the owner keeps one in-flight fetch per key. The request goes to the upper-tier PoP assigned to this origin, which runs the same hashing and coalescing across the misses of all 300 edges.
   7. The shield fetches from the origin over a warm connection, and both tiers store the response by its headers. The shield keeps pooled connections to busy origins, so a miss pays no TCP or TLS handshake. Cache-Control decides storage: s-maxage for us, private or no-store never stored, and the Surrogate-Key tags recorded for purge. The time the shield fetched the object from the origin travels with it to the edge, and purge decisions compare against that time.
   8. The owner streams the bytes to every waiting request and decides whether the object earns a place on disk. Waiters receive bytes as they arrive rather than after the whole object lands, so coalescing never delays a large file. The object is kept in RAM, but written to SSD only if a rotating Bloom filter has seen its key in the last few hours, which keeps one-hit wonders off the disk. The response reaches the browser with Age set, from the server that holds the connection.
2. Add a domain and a cache rule. The control-plane write path. A customer adds a domain, gets a certificate without doing anything, and a rule change reaches every server in seconds. The same machinery that makes changes fast is what could take every customer down at once, so validation and per-zone rollback are part of the path, not an afterthought.
   1. The customer adds shop.com and a cache rule through the API. The control plane writes to a strongly consistent config database, and every change to the zone gets the next version number. Validation runs before anything is accepted: schema, limits such as rules per zone and pattern size, and that the origin resolves.
   2. Once the customer’s DNS points at us, the certificate manager orders a certificate. ACME needs proof of control: an HTTP-01 token that our own edge serves under /.well-known/acme-challenge, or a DNS-01 record when we host the zone, which wildcards require. Orders go to at least two CAs, so one CA’s outage or rate limit does not stop onboarding. We generate the ECDSA key, and it never leaves the certificate system unencrypted.
   3. The certificate is stored with the zone and replicated to every PoP’s certificate store. About 15 M certificates at ~5 KB with chains is ~75 GB, small enough to replicate to every PoP, which keeps any remote call out of the handshake. Keys are encrypted at rest with a key only the TLS-terminating process can unwrap. Renewal runs at two thirds of the lifetime with jitter, about 250 k renewals a day.
   4. The distributor compiles the new config version and runs it through the real proxy in a sandbox. Compiling the rules to the binary form the proxy reads, then replaying synthetic requests through the production proxy build, catches configs that parse but misbehave: a pattern that backtracks, a redirect loop, a rule that crashes a worker. This is the customer lane: its blast radius is one zone, so it does not wait hours for a staged rollout.
   5. The version is appended to the replicated log and every server’s local store applies it. Relays stream the log to every PoP, and every server applies entries in sequence order, so it is always at one consistent position. Propagation takes a few seconds worldwide. Each server reports the sequence it has applied, so the API can tell the customer when the change is live everywhere.
   6. The first visitor’s handshake loads the new certificate on demand. Nothing is pushed into server memory ahead of time: the first ClientHello for shop.com on each server misses the in-memory LRU, reads the certificate from the PoP store and decrypts the key, about a millisecond, and every later handshake on that server is served from memory. That is what lets 15 M certificates live on a fleet that keeps only the hot ones in RAM.
   7. Requests use the new rule, and the zone’s error rate decides whether it stays. Servers report per-zone error and crash counts alongside the version they applied. If the zone’s 5xx rate or crash count jumps after the change, the distributor reverts the zone to its last good version everywhere within seconds and tells the customer. Changes that touch every customer, such as proxy releases and managed WAF rules, never use this lane: they go canary, 1 %, 10 %, 100 % over hours with health gates.
3. A 3 Tbit/s flood on one customer. The scale-breaking case for a CDN is an attack, not organic load. Anycast spreads it across the PoPs nearest the bots, every server drops junk at the cheapest layer it can, and per-zone limits keep the other customers on the same servers unaffected.
   1. A botnet floods the customer’s address with reflected UDP and SYN packets. Every PoP announces the same address, so each bot’s packets go to the PoP nearest that bot, and 3 Tbit/s from a botnet spread over many countries arrives as roughly 10 to 100 Gbit/s at each PoP instead of 3 Tbit/s at one. With 100 Tbit/s of capacity and 40 used at peak, the network has about 60 Tbit/s to spare. A per-PoP unicast address would have taken the whole flood at one site.
   2. Each server samples its packets, fingerprints the attack and installs a drop rule in its packet filter. Detection runs on every server against its own samples, so mitigation starts within seconds and does not depend on a central system that may itself be under attack. The rule matches the fingerprint (source port 53, packet length, a TTL pattern) and drops in XDP before the kernel allocates anything, at tens of millions of packets a second per server. SYN floods are answered with SYN cookies, so half-open connections cost no memory.
   3. HTTP floods that complete TLS reach the proxy, which applies the zone’s rate limits and challenges. Layer 7 requests look valid, so they are judged by rate and fingerprint: per client IP, per TLS fingerprint and per path, counted per server and synchronised across the PoP every second, which is approximate and good enough to stop a flood. Suspicious clients get a JavaScript or proof-of-work challenge rather than a hard block. The limits come from the zone’s config plus an attack-mode rule that can be switched on for that zone alone.
   4. Requests for cacheable URLs are answered from cache, and cache-busting variants are cut off at the key. A flood of GETs for /index.html costs a cache hit each, and the origin sees nothing. Attackers add random query strings to force misses, so static paths ignore unknown query parameters in the key, and a per-zone cap on origin fetches per PoP stops whatever misses remain. Coalescing does not help here, because every key is different; the key rule and the cap do.
   5. The mapper sees one PoP running hot and steers what it can away from it. If a PoP near a dense cluster of bots saturates, the mapper first moves what DNS controls: names on regional address groups get answers that avoid that PoP. As a last step the PoP withdraws only the attacked customer’s prefix, which pushes that attack onto neighbours that spread it again, while every other customer keeps being served locally. Withdrawing the whole PoP would move the attack and every innocent user along with it.
   6. Other customers sharing the attacked address are moved, and everyone else keeps normal latency. Junk is dropped before it costs CPU, and each zone’s proxy work is bounded by its limits, so a flood on one zone cannot spend another zone’s share. If one address keeps being targeted, the other zones on it are given different addresses through DNS, so the attacked address ends up carrying only its target. The 50 % utilisation target is what makes all of this possible: headroom is the defence.
4. The origin goes down: keep serving. The failure path. An origin starts timing out while its content is expiring. With stale-if-error, coalesced revalidation and a cap on origin concurrency, users see slightly old pages instead of errors, and the origin is not knocked over again as it recovers.
   1. A cached API response expires and its owner asks the shield to revalidate it. The response had s-maxage=60, stale-while-revalidate=30 and stale-if-error=86400. Inside the revalidate window the owner serves the stale copy at once and refreshes in the background, so no user waits. The refresh is a conditional request, so an unchanged object costs a 304 rather than a body.
   2. The shield merges every edge’s revalidation into one origin request, which times out. Edges across the world expire the same object within a minute of each other, and the shield turns all of them into one origin request. Origin timeouts are short (2 s to connect, 10 s to first byte), because a slow origin holding thousands of our connections is worse than a quick failure. An error on revalidation never overwrites the cached copy.
   3. The shield serves its stale copy downstream instead of the error. stale-if-error lets a cache use an expired response when the origin fails. We apply it by default for up to a day, unless the origin’s headers or the zone’s config set a different limit. The shield marks the copy as stale so the edge does not treat it as fresh for a full TTL, and the edge rechecks after a short backoff.
   4. Users keep getting the last good response from their own PoP. The product list is a few minutes old, which is far better than a 5xx. Objects with no stale copy (never cached, or private) do fail, and the error is cached for at most a few seconds, so a dead origin is not hammered but a recovered one is used at once.
   5. The shield marks the origin unhealthy, caps its concurrency and fails over if a backup exists. Timeouts per origin and active probes put the origin behind a circuit breaker: a few probes a second test it while everything else is served stale. If the zone has a backup origin, such as a second region or an object-storage copy, misses go there. A per-origin cap on concurrent fetches per shield server stops a thundering herd when the origin comes back.
   6. When the origin recovers, revalidations succeed and fresh copies replace the stale ones. The first successful probes close the breaker gradually, raising the concurrency cap over tens of seconds. Most revalidations return 304, so recovery costs headers, not bodies. Without coalescing and the cap, every edge would retry at the same moment and the origin would go straight back down.
5. Purge a tag worldwide in a second. The asynchronous path customers judge us on: one API call must stop 300 PoPs serving every object tagged product-123, within a second, with no message lost. Delivery is a sequenced log with acknowledgements, and applying a purge is an index lookup, never a scan.
   1. The customer’s CMS purges the product’s tag after a price change. Tags came from the origin’s Surrogate-Key header when each object was cached, so the CMS does not need to know which URLs show the product. The control plane authenticates the token, rate-limits purges per zone, and stamps the purge with a timestamp and a sequence number in a durable log before acknowledging.
   2. The purge is published to regional relays, which stream it to an agent in every PoP. About ten relays hold persistent streams to all 300 PoPs, so delivery is one hop over an open connection rather than 300 new ones. Purges are batched every 20 ms, which turns ~600 k PoP deliveries a second into ~15 k messages. Every message carries its sequence number.
   3. Every PoP, upper tiers included, marks the matching objects stale through a per-server tag index. Each server keeps an in-memory index from (zone, tag) to the objects it holds with that tag, built from Surrogate-Key as each object was stored, so a tag purge touches only matching objects and never scans a disk. A URL purge goes only to the key’s owner in each PoP, and a purge of a whole zone just bumps the zone’s generation number, which makes every older object stale on read.
   4. Each PoP acknowledges the sequence it has applied, and the control plane marks the purge complete. The purge is complete when all 300 PoPs report a sequence at or past it, typically under 500 ms and under 5 s at p99. A PoP that has not acknowledged is retried; one that loses the feed for more than 60 s withdraws its routes until it has replayed the log, because serving a purged price is worse than serving from the next PoP.
   5. The next request revalidates the stale copy, and a copy older than the purge is never cached again. Each PoP keeps the last minute of purges in a small table. When a copy arrives from upstream, its origin-fetch time (set by the shield and carried downstream) is checked against recent purges for its tags: if an edge raced ahead of a shield that had not applied the purge yet, the old copy is rejected and fetched again with a must-be-newer condition. A soft purge lets the stale copy be served while one coalesced revalidation runs; most come back 304 or with the new price.

Deep dives

The theory behind it

• CDNs and edge computing: How a content delivery network works, push vs pull, cache keys and TTLs, what to put at the edge, edge functions and KV, and the pitfalls of caching dynamic content.
• Global traffic management, DNS and anycast: How users reach the nearest healthy region: DNS resolution and TTLs, GeoDNS and latency-based routing, anycast, global load balancers, health checks and failover, the limits of DNS-based failover, and steering traffic during incidents and migrations.
• HTTP caching and cache headers: How browsers, CDNs and proxies decide what to cache: Cache-Control directives, max-age and s-maxage, ETags and conditional requests, immutable assets with fingerprinted URLs, stale-while-revalidate, Vary, private versus shared caches, and purging.

Related

• Design a URL Shortener
• Design YouTube
• Design Google Maps
• Design Netflix
• All 83 system design interview questions
• Run this question for a friend: the interviewer kit