Content Delivery Network (CDN)

A Content Delivery Network (CDN) is a geographically distributed group of servers that deliver content fast — typically static assets like HTML, CSS, JS, images, and video. The origin server holds the original content, while many edge servers cache copies near users. When a user in the UK requests a site hosted in the USA, the closest edge (e.g. London) serves it — far quicker than a round trip to the origin, while also reducing origin load.

1. Learning Objectives

By the end of this lesson, you will be able to:

• Explain the core architecture of a Content Delivery Network (CDN) and the purpose of Edge Servers.
• Distinguish between Push and Pull CDNs, evaluating the technical trade-offs of each.
• Describe routing mechanisms such as BGP Anycast and GeoIP DNS that direct traffic to the closest Point of Presence (PoP).
• Design caching policies utilizing HTTP headers (Cache-Control, ETag, Last-Modified) and implement cache invalidation strategies.
• Analyze production-grade optimization techniques, including dynamic content acceleration, SSL termination at the edge, and request collapsing.
• Evaluate failure modes (e.g., thundering herd, cache poisoning) and architect robust mitigation patterns.

2. Prerequisites

Before starting this topic, ensure you have a firm grasp of the following concepts:

• HTTP/HTTPS Protocols: Understanding headers, request/response cycles, and status codes (especially 200, 304, 404, 5xx).
• Domain Name System (DNS): How domain names resolve to IP addresses, A/AAAA records, and CNAME records.
• Latency & RTT: The physics of network transmission and how geographic distance affects Round-Trip Time (RTT).

3. Why This Topic Matters

In modern application development, speed translates directly to business value. A delay of just 100 milliseconds in page load time can reduce conversion rates by 7%. When a user requests a site, data must travel physically across fiber-optic cables. A request from London to a server in San Francisco takes at least 150ms of physical travel time (RTT) alone, not including server processing time.

A Content Delivery Network (CDN) solves this physical limitation. By caching content at the "edge" of the internet—close to the user's location—CDNs reduce latency to single-digit milliseconds. Furthermore, CDNs act as a massive buffer that shields origin web servers from sudden traffic spikes, slashes bandwidth costs by offloading transit traffic, and mitigates large-scale distributed denial-of-service (DDoS) attacks at the edge before they can saturate your network interfaces.

4. Real-world Analogy

Imagine a massive book publishing house headquartered in New York City (the Origin Server) that publishes a highly anticipated novel. Readers in London, Tokyo, Sydney, and Paris all want to read the book immediately.

If every single reader had to order the book directly from the NYC headquarters, it would take days or weeks for the book to ship across the ocean (high latency). Additionally, the NYC postal office would be completely overwhelmed with millions of individual packaging requests (origin overload).

To solve this, the publisher ships pallets of the book to local bookstore distribution hubs (Edge Servers / Points of Presence) in London, Tokyo, Sydney, and Paris. When a customer in Tokyo wants the book, they simply walk to their local neighborhood bookstore and purchase it instantly. If a local bookstore runs out of stock, they request a fresh batch from the NYC headquarters (cache miss), restock their shelves, and serve the customer. This local distribution model is precisely how a CDN speeds up digital content delivery.

5. Core Concepts

To build and operate systems utilizing a CDN, you must understand these foundational concepts:

• Origin Server: The source-of-truth server hosting your web application, database, or static assets (e.g., an AWS S3 bucket or a cluster of web servers).
• Edge Server (PoP): Point of Presence servers located at the edges of different networks globally. They terminate client connections, check local caches, and serve assets.
• Cache Hit / Cache Miss: A Cache Hit occurs when the Edge Server has the requested asset cached and serves it. A Cache Miss occurs when the Edge Server does not have the asset (or it has expired) and must fetch it from the origin.
• Time-to-Live (TTL): An expiration duration assigned to an asset that dictates how long an Edge Server is allowed to cache it before checking the origin for updates.
• Push vs. Pull CDNs:
  • Push CDN: The origin server proactively uploads (pushes) content to the CDN storage. The CDN holds it indefinitely until updated or deleted. Best for large, static, and infrequently updated files.
  • Pull CDN: The CDN automatically fetches (pulls) content from the origin on the first request by a user in a given region. The asset is then cached locally for subsequent users until the TTL expires.
• Anycast Routing: A network routing mechanism where multiple physical servers share a single IP address. BGP (Border Gateway Protocol) routes client requests automatically to the topologically closest server.

6. Visualization

The diagram below visualizes the difference between a cache hit (directly from the Edge Server) and a cache miss (requiring a round trip to the Origin Server).

7. How It Works

Let's walk through the end-to-end request lifecycle of a typical Pull CDN step-by-step:

1. DNS Resolution: The user types https://cdn.example.com/logo.png in their browser. The browser sends a query to local DNS servers. The authoritative DNS server for cdn.example.com uses GeoIP DNS or Anycast routing to return the IP address of the nearest CDN Point of Presence (PoP).
2. TCP/TLS Handshake at the Edge: The browser opens a TCP connection and completes the TLS handshake directly with the Edge Server. Because the Edge Server is geographically close, the handshake finishes in a fraction of the time it would take to reach the origin.
3. Cache Key Generation: The Edge Server receives the HTTP GET request. It generates a cache key (usually a hash of the URL, host header, and query parameters).
4. Cache Lookup: The Edge Server searches its high-speed local storage (RAM and NVMe SSD) for the key:
   • Cache Hit Scenario: If the key exists and the cached file is fresh (TTL is still valid), the Edge Server reads the content and sends it back to the client immediately.
   • Cache Miss Scenario: If the key is not found or the asset is stale, the Edge Server proceeds to fetch it.
5. Origin Fetch (Cache Miss): The Edge Server makes an HTTP request to the Origin Server (or a regional Origin Shield). It fetches the asset and the origin's response headers, which specify caching rules (e.g., Cache-Control: public, max-age=86400).
6. Caching and Delivery: The Edge Server saves a copy of the asset in its local storage and forwards the response to the client. Subsequent requests from other users in the same region will hit the cache, avoiding the origin hop.

8. Internal Architecture

Inside a CDN Point of Presence (PoP), multiple servers and network appliances cooperate to route, cache, and filter traffic. The system architecture is divided into the following key components:

9. Request Lifecycle

Let's trace the sequence of operations for a single request received at a CDN Edge Server:

1. Ingress: Packet arrives at the PoP's router via Anycast. It is directed to a regional L4/L7 load balancer and routed to an available Edge Proxy node.
2. TLS Termination: The Edge Proxy completes TLS negotiation using SNI (Server Name Indication) to locate the correct customer certificate.
3. Request Parsing & WAF: Headers are parsed. The Edge checks for malicious signatures (WAF phase) and rate-limit states.
4. Cache Key Generation: The path is normalized (lowercase, query parameters sorted, specific headers appended if configured). A hash of this normalized string becomes the cache key.
5. Cache Check:
   • Check RAM cache. Found? Deliver response instantly.
   • Check SSD storage. Found? Move to RAM, deliver response.
   • Not Found? Proceed to Cache Miss.
6. Origin Request Collapsing (Coalescing): If thousands of requests for the same missing key arrive simultaneously, the Edge blocks the other requests and issues a single connection to the origin to fetch the file, preventing origin overload.
7. Origin Retrieval: The file is retrieved from the origin or Origin Shield. If the origin returns a 304 Not Modified, the edge updates the TTL of the cached entry. If it returns 200 OK, it stores the response and returns it.
8. Egress Processing: The response is compressed (e.g., Brotli/Gzip), security headers (HSTS, CSP) are added, and data is flushed to the client socket.

10. Deep Dive

1. Cache Validation & HTTP Headers

To control cache behavior, the origin server and CDN rely on specific HTTP headers:

• Cache-Control: s-maxage=<seconds>: Tells the shared CDN cache (and not browser caches) how long to store the asset.
• Cache-Control: public: Indicates that the response may be cached by any cache (CDN, browser, ISP).
• Cache-Control: private: Restricts caching to the end-user's browser. The CDN must never cache private responses.
• ETag (Entity Tag): A unique string hash of the asset (e.g., W/"5f4a-71bc"). When an asset expires, the CDN sends If-None-Match: W/"5f4a-71bc" to the origin. If the origin returns 304 Not Modified, the CDN marks the cache fresh without downloading the body again.
• Stale-While-Revalidate=<seconds>: Instructs the CDN to serve stale content to the user immediately on a cache miss, while asynchronously requesting the fresh asset from the origin in the background.

2. Cache Invalidation and Propagation

When content changes, waiting for the TTL to expire is unacceptable. Systems require Cache Invalidation. There are two primary types:

• Hard Purge: Immediately deletes the cached asset from the storage index. The next request will block on an origin fetch.
• Soft Purge (Invalidate): Marks the cached asset as stale. The edge will serve it but immediately trigger a background validation (using If-None-Match) to update it.

Invalidation commands propagate globally across the control plane via high-speed pub-sub networks, usually taking between 150ms to 2 seconds to purge the cache at all edges.

3. Edge Compute (Serverless at the Edge)

Modern CDNs offer Edge Compute. Running code in lightweight V8 Isolates or WebAssembly (Wasm) runtimes directly on the edge nodes allows developers to:

• Perform JWT authorization checks before hitting the cache or origin.
• A/B test by dynamically rewriting request paths or injecting different cookies.
• Resize images on-the-fly depending on the client's User-Agent.
• Construct custom HTML pages at the edge by stitching together multiple API responses.

11. Production Example: Netflix Open Connect

To handle over 15% of global downstream internet traffic without crushing public networks, Netflix built its own custom CDN called Open Connect.

Rather than relying entirely on public CDN vendors, Netflix installs custom-built server appliances called Open Connect Appliances (OCAs) directly inside ISP datacenters and internet exchange points (IXPs) worldwide. These appliances are provided to ISPs free of charge. Here is how it operates:

• Proactive Pre-positioning (Push Model): Netflix predicts which shows will be popular in specific regions. During off-peak overnight hours, the AWS-based control plane instructs OCAs to download these video files (up to 4K resolutions) directly from AWS.
• Zero Origin Cost for Video Delivery: When a user presses play, the client app contacts the AWS control plane, which determines the client's network path and redirects the client directly to the OCA located inside their own ISP's building.
• Ultra-High Throughput: Because the video file is streamed from a server physically located in the same building as the ISP's regional network, there is zero transit fee, zero congestion, and almost infinite throughput, providing instantaneous playback.

12. Advantages

• Extremely Low Latency: Serves content to users within 10-30ms by eliminating long-distance trans-oceanic fiber hops.
• Drastic Bandwidth Savings: Caching offsets up to 95%+ of egress traffic from the origin server, significantly lowering cloud provider data transfer bills.
• High Resilience & Availability: In the event of an origin crash, CDNs can continue serving cached content indefinitely using stale-on-error strategies.
• Massive DDoS Protection: Edge networks can absorb multi-terabit volumetric attacks, shielding the origin from receiving raw malicious traffic.
• Reduced Origin Load: Origin servers only process dynamic operations and cache misses, drastically decreasing CPU/Memory resource demands.

13. Limitations

• Cache Staleness: If invalidation mechanisms fail or are delayed, users will receive outdated information, which can be critical for financial or news sites.
• Debugging Complexity: Tracking down why a specific asset is returning a stale version or incorrect CORS headers involves auditing complex caching rules across dozens of global nodes.
• Cold Starts: Long-tail (rarely accessed) content is constantly evicted from the cache. The first user to request it experiences high latency.
• Cost: Enterprise CDN features like Advanced Web Application Firewalls (WAF), image optimization, and edge compute can scale rapidly in cost.

14. Trade-offs

Push CDN vs. Pull CDN

Push CDN: You upload files manually or via scripts. Caches are 100% warm, guaranteeing hit rate, but requires complex automation pipelines to update files and handle synchronization failures.

Pull CDN: Automated, lazy-loaded caching. Extremely simple to set up, but the first user in each region pays a high latency tax (cold start), and sudden traffic sweeps can flood the origin with simultaneous cache misses.

TTL Duration (Short vs. Long)

Short TTL: Maximizes fresh data at the cost of cache hit ratio, leading to increased load on the origin server.

Long TTL: Maximizes cache hit ratio and offloads the origin, but requires robust, proactive invalidation systems or version-based content hashing (cache busting) to update.

Cache-Key Cardinality

High Cardinality: Including client country, device type, or cookies in the cache key creates highly personalized caches but splits (fragments) the cache storage. This destroys the Cache Hit Ratio, as the same file must be cached independently for every combination.

15. Performance Considerations

• Cache Hit Ratio (CHR) Monitoring: Ensure CHR is monitored continuously. A drop in CHR usually indicates cache fragmentation or incorrect headers. Aim for >90% for static assets.
• Edge SSL/TLS Termination: Ensure TLS is terminated at the edge. Negating the 3-way handshake over the WAN decreases time-to-first-byte (TTFB) significantly.
• Brotli Compression: Brotli offers up to 20-30% better compression than Gzip for text assets (HTML, JS, CSS). Ensure the CDN is configured to negotiate Brotli compression at the edge.
• Connection Pooling: Maintain persistent keep-alive TCP connections between CDN edge nodes and the origin server. This eliminates connection handshakes when forwarding cache misses.

16. Failure Scenarios

1. The Thundering Herd / Cache Stampede

Scenario: A popular cached asset (e.g., the homepage JS file) expires. Instantly, 10,000 requests hit the edge servers. All edge servers observe a cache miss and forward the request to the origin simultaneously, crashing it.

Mitigation: Implement Request Collapsing at the edge. When a miss occurs, the first edge node locks the key and fetches from the origin, forcing all other concurrent requests to wait and consume the returned response. Adding an Origin Shield (an intermediate caching tier) also collapses misses from multiple PoPs before hitting the origin database.

2. Cache Poisoning

Scenario: An attacker exploits a disparity in how the CDN and the origin handle specific HTTP headers (e.g., X-Forwarded-Host). The attacker issues a request that makes the origin return a malicious payload, which the CDN then caches and serves to all subsequent users.

Mitigation: Disable caching for requests with suspicious headers. Avoid including untrusted user-controlled headers in cache keys, or use strict CDN-side header normalization.

3. Regional Outages & BGP Route Flapping

Scenario: A CDN provider experiences a global routing failure, causing traffic to drop or loop infinitely.

Mitigation: Implement a Multi-CDN strategy. Use a smart DNS router (e.g., NS1, Route 53) that monitors CDN health and dynamically switches traffic to an alternate CDN provider within seconds if the primary drops.

17. Best Practices

• Implement Cache Busting (Immutable Assets): Use content hashing in filename assets (e.g., bundle.d82fa9.js). Set Cache-Control: public, max-age=31536000, immutable. If the file changes, change its hash. This guarantees zero stale files and 100% cache utilization.
• Enable stale-if-error and stale-while-revalidate: Protect the user experience. Serving an older cached page is always better than returning a 502/504 Bad Gateway screen.
• Secure CDN-to-Origin Connections: Ensure the origin server is firewall-protected and only accepts incoming requests from known CDN IP ranges or via mutual TLS (mTLS).
• Keep Cache Keys Simple: Avoid using high-cardinality headers or query parameters (like UTM tracking parameters) in the cache key. Strip query parameters that don't change the response body.

18. Common Mistakes

• Caching Sensitive User Information: Configuring the CDN to cache pages containing private session tokens, PII, or JWTs. This leads to user A seeing user B's profile. Always verify that pages containing personal details return Cache-Control: private, no-store.
• Caching API Error Responses: Failing to specify caching rules on 5xx or 4xx responses, causing the CDN to cache an error page (e.g., a database connection error) and serve it for the duration of the TTL.
• Inconsistent CORS Configuration: Forgetting to set Vary: Origin. If a request from domainA.com requests a resource first, the CDN caches the CORS headers for domainA.com. When domainB.com requests the same file, the CDN serves the cached headers, triggering a CORS block.

19. Implementation: Mock CDN Edge Cache

The following TypeScript code implements a mock CDN edge server proxy. It incorporates an LRU cache eviction policy, TTL expiration checks, ETag validation, and request collapsing (to prevent the thundering herd problem when many requests miss simultaneously).

20. Interview Questions

Easy: What is the primary difference between a Push CDN and a Pull CDN?

Answer: In a Push CDN, the origin server manually uploads (pushes) content to the CDN's storage nodes. The CDN serves this content until it is explicitly overwritten or deleted. In a Pull CDN, the CDN edge servers lazily fetch (pull) content from the origin on the first request by a user in that region, caching it with a TTL. Push CDNs are ideal for static, large, infrequently updated assets (like app downloads or PDF catalogs), whereas Pull CDNs require less manual maintenance and are better for highly dynamic websites or general-purpose web assets.

Medium: How does a CDN determine which Edge server (PoP) is closest to the client?

Answer: CDNs use two primary network routing techniques:

• GeoIP DNS Routing: The client issues a DNS request. The CDN's DNS server inspects the resolver's source IP address, queries a database of IP-to-location mappings, and returns the IP of the closest PoP.
• BGP Anycast Routing: Multiple physical PoPs around the world advertise the same IP address using Border Gateway Protocol (BGP). The routers on the internet path naturally route the client's packets to the topologically closest node. Anycast is preferred in modern CDNs as it fails over automatically and avoids DNS caching delays.

Hard: What is the thundering herd problem, and how do you design a CDN/Origin architecture to mitigate it?

Answer: The thundering herd (or cache stampede) occurs when a popular asset expires. Thousands of concurrent client requests hit the edge, find a cache miss, and forward their requests to the origin simultaneously, potentially exhausting the origin's database and web server threads.

To mitigate this, design the CDN with Request Collapsing: the first edge proxy to observe the miss locks the cache key, creates an active promise to the origin, and forces subsequent concurrent requests for that key to wait until the single request returns. Additionally, introduce an Origin Shield (a second-tier cache layer placed between the edge and the origin) to collapse misses across different global PoPs. Finally, configure stale-while-revalidate so that edge servers serve expired items while resolving the new version in the background.

21. Practice Exercises

Easy: Latency Savings Estimation

Calculate the latency savings for a web app that loads 10 assets (sequentially, for simplicity, and over separate TCP handshakes). The Unicast Origin server is in Tokyo (RTT = 180ms), and the CDN Edge PoP is in London (RTT = 15ms). Assume 1 RTT for TCP, 1 RTT for TLS, and 1 RTT for the HTTP request itself per asset. (NO answer provided, solve on your own).

Medium: DNS Traffic Splitting Layout

Draw a high-level architectural block diagram representing a multi-CDN layout. Detail how client DNS requests are parsed by a primary DNS router and split between Akamai (60% weight) and Cloudflare (40% weight), including failure monitoring hooks. (NO answer provided, solve on your own).

Hard: Highly Specialized Cache-Key Strategy

Design a cache-key configuration structure for an international e-commerce catalog page. The catalog must serve different languages (English, German, Chinese), accept mobile/desktop screen layouts, and accommodate user location settings (US, EU, UK). Explain how you will structure your cache keys to avoid cache fragmentation and key explosion while ensuring users do not receive mismatched layouts or languages. (NO answer provided, solve on your own).

22. Challenge Problem

Scenario: You are the lead system architect at a global news platform. During breaking news events, writers edit article copy frequently, and editorial images are replaced. The platform experiences traffic spikes of up to 100,000 requests per second. The cache invalidation system must ensure that once an editor clicks "Publish," the cache across all 150+ edge locations globally is invalidated within 2 seconds.

Requirements:

• Handle up to 50,000 individual asset purges per minute.
• Survive intermittent network partitions between the origin network and various regional edge PoPs.
• Ensure that users never see a broken page state where the HTML points to a deleted image.
• Write a 3-page architectural plan showing your purge pipeline components (Message Broker, Invalidation Fan-out workers, Edge API agents, and fallback policies).

23. Summary

A Content Delivery Network (CDN) is the foundation of high-performance web architecture. By distributing edge servers geographically close to users, CDNs decrease connection latencies (RTT), terminate TLS close to users, and serve cached files. Utilizing Anycast routing allows CDNs to direct users to the optimal Point of Presence (PoP) transparently.

Caching dynamics are controlled through HTTP headers (Cache-Control, ETags, Last-Modified). Designing an efficient system requires balancing TTL duration against cache-key granularity and invalidation requirements. Modern features like Origin Shields, request collapsing, and Edge Compute enable CDNs to serve as robust, programmable application layers that defend and scale backend systems.

24. Cheat Sheet

25. Quiz

1. Which HTTP header controls the caching time specifically on the CDN edge proxy and is ignored by standard browser caches?
   • A) Cache-Control: max-age
   • B) Cache-Control: s-maxage
   • C) Cache-Control: private
   • D) ETag

   Answer: B

   Explanation: The s-maxage directive applies specifically to public/shared caches (like CDNs) and overrides the standard max-age directive, which browser caches prioritize.

2. How does BGP Anycast routing deliver traffic to the nearest CDN Edge PoP?
   • A) It dynamically alters DNS records based on the client's GPS coordinates.
   • B) It routes requests to multiple servers sharing the same IP address, forwarding packets to the topologically closest node via standard internet routing pathways.
   • C) It routes traffic through a single central controller that load-balances connections.
   • D) It uses client cookies to track and pin the client's session to a single server.

   Answer: B

   Explanation: BGP Anycast shares a single IP address across multiple physical nodes. Internet routers route packets along the shortest topological path, naturally landing at the closest node.

3. What happens during a Pull CDN cache miss?
   • A) The request fails and returns a 404 error.
   • B) The client is redirected to download the asset from a peer client.
   • C) The Edge Server requests the asset from the origin, caches it locally, and delivers the response to the client.
   • D) The Edge server uploads the client's file directly to the origin database.

   Answer: C

   Explanation: A Pull CDN is lazy-loaded. On a cache miss, the Edge server fetches the file from the origin server, saves a copy in its cache directory, and forwards it to the requesting client.

4. Which design pattern directly mitigates the "Thundering Herd" problem?
   • A) Route weight adjustments
   • B) Cache key fragmentation
   • C) Request collapsing (coalescing)
   • D) Shortening the TTL

   Answer: C

   Explanation: Request collapsing intercepts duplicate concurrent requests for a single missing cache key and consolidates them into a single request to the origin, shielding it from traffic spikes.

5. Under what condition will an Origin server return an HTTP status code 304?
   • A) When the asset is deleted.
   • B) When the client requests an asset using an invalid method.
   • C) When a validation request (via If-None-Match) indicates the cached ETag is still identical to the origin version.
   • D) When the cache has a TTL of zero.

   Answer: C

   Explanation: The status code 304 Not Modified is returned when the ETag validation matches, telling the CDN that its cached resource is still fresh and does not need to be re-downloaded.

6. Which Cache-Control header prevents any cache (both CDN and browser) from storing a response?
   • A) Cache-Control: private
   • B) Cache-Control: no-cache
   • C) Cache-Control: no-store
   • D) Cache-Control: public

   Answer: C

   Explanation: The no-store directive prohibits any cache from storing the response payload under any circumstance. (Note: no-cache actually allows caching but forces immediate revalidation).

7. What is the benefit of terminating SSL/TLS connections at the CDN edge?
   • A) It makes the origin server bypass encryption entirely.
   • B) It eliminates cryptographic handshakes close to the user, shortening the physical connection negotiation path and improving Time-To-First-Byte (TTFB).
   • C) It increases the security of data stored in the database.
   • D) It prevents browser caching of dynamic content.

   Answer: B

   Explanation: Cryptographic handshakes require multiple round-trips. Completing them close to the client (at the Edge) avoids executing these round-trips over long-distance WAN lines.

8. What happens when a cache key has high cardinality?
   • A) The cache hit ratio is maximized.
   • B) Cache storage becomes fragmented, resulting in lower Cache Hit Ratios because separate instances of the same asset must be stored for minor header variations.
   • C) All requests are routed to a single CPU node.
   • D) The origin server stops accepting new connections.

   Answer: B

   Explanation: High cardinality keys include many variables (e.g., query params, headers). This creates separate entries for identical assets, which fragments the cache and increases misses.

9. How does Netflix Open Connect optimize delivery for high-bandwidth video streams?
   • A) By compression formats and live transcoding at the user's browser.
   • B) By pre-positioning predicted popular videos directly inside ISP server appliances during off-peak hours.
   • C) By routing all traffic through Amazon S3 buckets in North Virginia.
   • D) By forcing all users to download videos via peer-to-peer torrent channels.

   Answer: B

   Explanation: Netflix pre-positions content on Open Connect Appliances (OCAs) located directly inside partner ISP networks overnight, meaning local users stream directly from inside their own ISP's network.

10. What does a "Soft Purge" do during CDN cache invalidation?
    • A) It deletes the file from the origin server completely.
    • B) It marks the cached asset as stale but continues to serve it while initiating a background fetch to revalidate and update the entry from the origin.
    • C) It resets the CPU of the edge nodes.
    • D) It removes security filters on the edge.

    Answer: B

    Explanation: A soft purge avoids blocking clients. It marks the cache stale and updates it asynchronously via background revalidation requests, avoiding user-facing latency.

26. Further Reading

• High Performance Browser Networking (Ilya Grigorik): Excellent chapter on CDN architectures, routing protocols, and latency calculations.
• RFC 7234 (HTTP/1.1 Caching): The official Internet Engineering Task Force (IETF) specification detailing cache rules, headers, and validation behaviors.
• The Cloudflare Blog: Excellent technical posts detailing BGP Anycast routing implementation, Edge compute internals, and WAF mitigation stories.

27. Next Lesson Preview

In the next lesson, we will explore Domain Name Systems (DNS). You will learn about root servers, Top-Level Domain (TLD) servers, authoritative nameservers, and how DNS recursive resolvers orchestrate name lookup resolutions globally. This will explain how custom domain mappings route client requests to CDN edges.