CDN - How Content Delivery Networks Work, Edge Caching

🎯

CDN - How Content Delivery Networks Work, Edge Caching

mediumNETWORKSAmazonGoogleFlipkart

Imagine streaming a live cricket match from India to millions of viewers worldwide without buffering delays or server crashes.

💡 Beginners often confuse CDNs with just caching proxies or think CDNs only replicate content without understanding the dynamic routing and caching strategies involved.

📋

Interview Question

Explain how Content Delivery Networks (CDNs) work, focusing on the role of edge caching and how it reduces latency for end users.

Edge servers and origin serversCaching and Time-To-Live (TTL)Geo-routing and latency optimization

💡

Scenario & Trace

ScenarioA user in New York requests a popular video hosted on a server in California.

1. User sends HTTP request → 2. DNS resolves to nearest CDN edge server in New York → 3. Edge server checks cache for video → 4. If cached and TTL valid, edge server serves video directly → 5. If not cached or TTL expired, edge server fetches video from origin server in California → 6. Edge caches the video and serves user → 7. Subsequent nearby users get video from edge cache, reducing latency and load on origin.

ScenarioA new product image is updated on an e-commerce site’s origin server.

1. Origin server updates image → 2. Edge servers still have old cached image with TTL not expired → 3. User requests image from edge server → 4. Edge serves stale image until TTL expires or cache is purged → 5. After TTL expiry or purge, edge fetches updated image from origin → 6. Users then see the updated image.

• What happens if two edge servers have inconsistent cached versions due to TTL differences?
• How does CDN handle cache misses when the origin server is temporarily unreachable?
• What if a user is located in a region with no nearby edge servers?

⚠️

Common Mistakes

Thinking CDN is just a caching proxy without geo-distribution

Interviewer doubts your understanding of CDN scale and latency optimization

✅ Emphasize the global distribution of edge servers and geo-routing

Assuming cached content is always fresh and instantly updated

Interviewer questions your grasp of TTL and cache invalidation

✅ Explain TTL, cache expiry, and purging mechanisms that balance freshness and performance

Ignoring what happens on cache misses or origin failures

Interviewer suspects you don't understand CDN fault tolerance

✅ Discuss fallback to origin, error handling, and retry strategies

Confusing CDN with DNS or load balancers alone

Interviewer thinks you lack clarity on CDN components

✅ Clarify that DNS and load balancing are part of CDN routing but CDN includes caching and edge servers

🧠

Basic Definition - What It Is

💡 This is the minimum you must know to explain CDNs in a simple interview setting.

Intuition

A CDN is a network of servers distributed globally to deliver content faster by caching it closer to users.

Explanation

Content Delivery Networks (CDNs) are systems of geographically distributed servers that cache copies of content from an origin server. When a user requests content, the CDN directs the request to the nearest edge server, which serves the cached content if available. This reduces the distance data travels, lowering latency and improving load times. Edge caching means storing content temporarily on these edge servers with a validity period called TTL (Time-To-Live). If the cached content is fresh, it is served directly; otherwise, the edge server fetches updated content from the origin.

Memory Hook

💡 Think of a CDN like a chain of local libraries (edge servers) stocked with popular books (content) so readers (users) don’t have to travel to the main library (origin server) far away.

Illustrative Code

# No code for this conceptual approach
# Explanation focused, no implementation needed

Interview Questions

❓ What is the primary purpose of a CDN?

• Reduce latency by caching content closer to users
• Decrease load on origin servers

❓ What role does TTL play in edge caching?

• Defines how long cached content is considered fresh
• Controls when edge server fetches updated content from origin

⏱

Depth Level

Interview Time30 seconds

Depthbasic

This approach is conceptual and does not involve algorithmic complexity. It covers fundamental understanding suitable for screening or quick conceptual questions.

Interview Target: Minimum floor - never go below this

Knowing only this will help you pass initial screening but is insufficient for deeper technical discussions.

🧠

Mechanism Depth - How It Works

💡 This is what product companies expect for on-site interviews and deeper understanding.

Intuition

CDNs use geo-routing to direct user requests to the optimal edge server, which caches content with TTL and fetches from origin on cache misses or expiry, balancing freshness and latency.

Explanation

A CDN operates by deploying multiple edge servers strategically across geographic locations. When a user requests content, DNS or HTTP redirection mechanisms route the request to the nearest or best-performing edge server based on latency, load, and network conditions (geo-routing). The edge server checks its cache for the requested content. If the content is cached and the TTL has not expired, it serves the content immediately, minimizing latency. If the content is missing or stale, the edge server fetches the latest version from the origin server, caches it, and then serves the user. This caching strategy reduces bandwidth usage and origin load. CDNs also handle cache invalidation through TTL expiry or explicit purging to ensure content freshness. Additionally, CDNs implement fallback mechanisms for origin unavailability and optimize routing to handle users in regions without nearby edge servers.

Memory Hook

💡 Imagine a relay race where runners (edge servers) pass the baton (content) quickly to the next runner closest to the finish line (user), but occasionally must run back to the start (origin) to get a fresh baton when theirs expires.

Illustrative Code

# No code for this conceptual approach
# Explanation focused, no implementation needed

Interview Questions

❓ How does geo-routing improve CDN performance?

• Routes user requests to nearest or fastest edge server
• Reduces latency and network congestion

❓ What happens on a cache miss at the edge server?

• Edge server requests content from origin
• Caches the content for future requests
• Serves content to user after fetching

❓ How does TTL affect content freshness and CDN efficiency?

• Short TTL improves freshness but increases origin load
• Long TTL reduces origin load but risks stale content

⏱

Depth Level

Interview Time2-3 minutes

Depthintermediate

This approach is conceptual and does not involve algorithmic complexity. It demonstrates understanding of CDN internals, trade-offs, and real-world operation.

Interview Target: Target level for FAANG on-sites

Mastering this level distinguishes you from most candidates and prepares you for follow-up questions.

📊

Explanation Depth Levels

💡 Choose your explanation depth based on interview stage and company expectations.

Level	Interview Time	Suitable For	Risk
Basic Definition	30s	Screening call or quick conceptual questions	Too shallow for on-site or technical deep dives
Mechanism Depth	2-3 minutes	On-site interviews at product companies like FAANG	Requires good understanding; missing details may lead to follow-up questions

💼

Interview Strategy

💡 Use this guide to structure your explanation clearly and confidently before every mock or real interview.

How to Present

Start with a concise definition of what a CDN is and its purpose.Give a relatable example or analogy to make the concept tangible.Explain the internal mechanism focusing on edge caching, TTL, and geo-routing.Discuss common edge cases and how CDNs handle them.

Time Allocation

Definition: 30s → Example: 1min → Mechanism: 2min → Edge cases: 30s. Total ~4min

What the Interviewer Tests

Interviewer checks your clarity on CDN purpose, caching mechanics, latency reduction, and handling of cache freshness and failures.

Common Follow-ups

• How do CDNs handle dynamic content that changes frequently? → Use cache bypass or short TTL.
• What strategies exist for cache invalidation? → TTL expiry, purging, versioning.

💡 These follow-ups test your knowledge of CDN limitations and advanced features.

🔍

Pattern Recognition

When to Use

Asked when interviewers want to assess understanding of web performance, scalability, and distributed systems.

Signature Phrases

Explain how a CDN worksWhat is edge caching?How does TTL affect CDN performance?

NOT This Pattern When

Similar Problems

Practice

1. In a local area network, when a device needs to send a packet to another device but only knows the destination IP address, which component is responsible for resolving the corresponding MAC address?

easy

A. The DNS server

B. The ARP protocol

C. The DHCP server

D. The routing table

Solution

1. Step 1: Identify the role of ARP

   ARP (Address Resolution Protocol) is specifically designed to map IP addresses to MAC addresses within a local network segment.

2. Step 2: Why not DNS?

   DNS resolves domain names to IP addresses, not MAC addresses.

3. Step 3: Why not DHCP?

   DHCP assigns IP addresses dynamically but does not resolve MAC addresses.

4. Step 4: Why not routing table?

   Routing tables determine the next hop IP address but do not resolve MAC addresses.

5. Final Answer:

   Option B -> Option B

6. Quick Check:

   ARP is the protocol that resolves IP to MAC addresses on local networks [OK]

Hint: ARP maps IP to MAC on local networks [OK]

Common Mistakes:

• Confusing DNS with ARP
• Thinking DHCP handles MAC resolution

2. Trace the sequence of steps during a TLS handshake when a client connects to an HTTPS server.

easy

A. Client sends ClientHello, server responds with ServerHello and certificate, client verifies certificate, client sends encrypted pre-master secret, server decrypts it, both derive symmetric keys

B. Client sends encrypted data, server responds with certificate, then symmetric key is exchanged

C. Client sends HTTP request, server sends certificate, client sends symmetric key in plaintext, handshake completes

D. Client sends ClientHello, server sends ServerHello, handshake completes without certificate exchange

Solution

1. Step 1: Identify the TLS handshake flow

   The handshake starts with ClientHello, followed by ServerHello and certificate, then client verifies certificate, sends encrypted pre-master secret, and both derive symmetric keys.

2. Step 2: Evaluate each option

   A: Correct sequence including ClientHello, ServerHello, certificate exchange, verification, encrypted pre-master secret, and key derivation.
   B: Incorrect order and missing ClientHello/ServerHello steps.
   C: Client sends HTTP request too early and symmetric key is never sent in plaintext.
   D: Certificate exchange is mandatory for authentication, so this is incomplete.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Remember the handshake involves hello messages, certificate exchange, key exchange, and symmetric key derivation.

Hint: TLS handshake = Hello messages + certificate + encrypted key exchange

Common Mistakes:

• Confusing when the certificate is sent
• Assuming symmetric keys are exchanged in plaintext
• Skipping certificate verification step

3. Which of the following statements about Distance Vector routing is INCORRECT?

medium

A. Routers using Distance Vector routing have complete knowledge of the entire network topology

B. Distance Vector routing can suffer from the count-to-infinity problem causing slow convergence

C. Distance Vector routing updates are sent only to immediate neighbors

D. Split horizon and poison reverse are techniques used to prevent routing loops in Distance Vector

Solution

1. Step 1: Recall Distance Vector knowledge scope

   Distance Vector routers only know routes advertised by neighbors, not the full network topology.

2. Step 2: Analyze each statement

   Distance Vector routing can suffer from the count-to-infinity problem causing slow convergence is true; count-to-infinity is a known Distance Vector issue. Distance Vector routing updates are sent only to immediate neighbors is true; updates go only to neighbors. Split horizon and poison reverse are techniques used to prevent routing loops in Distance Vector is true; split horizon and poison reverse help prevent loops.

3. Step 3: Identify incorrect statement

   Routers using Distance Vector routing have complete knowledge of the entire network topology is false because complete topology knowledge is a characteristic of Link State routing, not Distance Vector.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Distance Vector routers have partial, neighbor-based knowledge only.

Hint: Full topology knowledge -> Link State, not Distance Vector

Common Mistakes:

• Assuming Distance Vector routers know entire topology
• Confusing update scope between routing types
• Ignoring loop prevention techniques

4. Which of the following statements about TCP acknowledgment numbers is INCORRECT?

medium

A. TCP acknowledgment numbers are cumulative and indicate the next expected byte from the sender

B. Duplicate ACKs always indicate packet loss and require immediate retransmission

C. An ACK number can acknowledge multiple segments if they are received in order

D. ACK numbers help the sender detect which data has been successfully received

Solution

1. Step 1: Review ACK number behavior

   ACK numbers are cumulative and indicate the next byte expected, acknowledging all prior bytes.

2. Step 2: Analyze duplicate ACKs

   Duplicate ACKs often indicate packet loss but can also occur due to reordering; immediate retransmission is triggered only after three duplicates (fast retransmit).

3. Step 3: Evaluate options

   TCP acknowledgment numbers are cumulative and indicate the next expected byte from the sender is correct. Duplicate ACKs always indicate packet loss and require immediate retransmission is incorrect because duplicate ACKs do not always require immediate retransmission. An ACK number can acknowledge multiple segments if they are received in order is correct as ACK numbers can acknowledge multiple segments. ACK numbers help the sender detect which data has been successfully received is correct.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   Duplicate ACKs signal potential loss but do not always trigger immediate retransmission.

Hint: Duplicate ACKs ≠ always immediate retransmit; need 3 duplicates.

Common Mistakes:

• Assuming every duplicate ACK means packet loss
• Confusing cumulative ACKs with selective ACKs
• Believing ACK numbers acknowledge individual segments only

5. Which of the following is a common misconception about the resource utilization of Server-Sent Events (SSE) compared to WebSockets?

medium

A. SSE uses fewer server resources than WebSockets because it only supports unidirectional communication

B. SSE cannot be used over HTTPS, limiting its security compared to WebSockets

C. SSE maintains a single persistent HTTP connection, reducing latency compared to HTTP Long Polling

D. SSE requires a new HTTP connection for each event, increasing overhead compared to WebSockets

Solution

1. Step 1: Understand SSE connection model

   SSE maintains a single persistent HTTP connection over which events are streamed.

2. Step 2: Analyze resource usage

   Because SSE uses one persistent connection, it avoids the overhead of repeatedly opening new connections.

3. Step 3: Evaluate options

   SSE requires a new HTTP connection for each event, increasing overhead compared to WebSockets is false; SSE uses a single persistent connection. SSE uses fewer server resources than WebSockets because it only supports unidirectional communication is true. SSE maintains a single persistent HTTP connection, reducing latency compared to HTTP Long Polling is true. SSE cannot be used over HTTPS, limiting its security compared to WebSockets is a common misconception and is false; SSE works over HTTPS.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   SSE works over HTTPS; it is not limited in security compared to WebSockets

Hint: SSE = single persistent connection, supports HTTPS

Common Mistakes:

• Assuming SSE opens a new HTTP request for every event
• Believing SSE is bidirectional like WebSocket
• Thinking SSE cannot be secured with HTTPS