Bird
Raised Fist0
Interview Prepcomputer-networksmediumAmazonGoogleFlipkartSwiggyPhonePeZeptoRazorpay

CDN - How Content Delivery Networks Work, Edge Caching

Choose your preparation mode3 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Steps
setup

Client Initiates Content Request

The client sends an HTTP GET request for content to the CDN domain. The packet leaves the client node and heads towards the DNS server to resolve the CDN domain.

💡 This step sets up the initial request, showing how a client starts the content retrieval process by querying DNS to find the nearest CDN edge server.
Line:# No code - conceptual step
💡 Understanding that content delivery starts with domain resolution is crucial to grasping CDN operation.
📊
CDN - How Content Delivery Networks Work, Edge Caching - Watch the Algorithm Execute, Step by Step
Watching this step-by-step packet flow visualization reveals the dynamic interactions between client, CDN edge servers, origin servers, and network devices, clarifying the caching mechanism and routing decisions.
Step 1/11
·Active fillAnswer cell
Client sends initial HTTP GET request to router.
Hop: 1
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromclient
torouter1
📄 payloadHTTP GET www.cdn-example.com
🔌 protocolHTTP
🚩 flags
src192.0.2.10:54321
dst198.51.100.53:80
dataHTTP GET www.cdn-example.com
Client → Router 1: HTTP GET www.cdn-example.com
Router forwards DNS query to DNS server.
Hop: 2
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromrouter1
todns
📄 payloadDNS Query www.cdn-example.com
🔌 protocolDNS
🚩 flags
src192.0.2.1:53
dst198.51.100.1:53
dataDNS Query www.cdn-example.com
Client → Router 1: HTTP GET www.cdn-example.com
Router 1 → DNS Server: DNS Query www.cdn-example.com
DNS server sends IP of nearest CDN edge server to router.
Hop: 3
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromdns
torouter1
📄 payloadDNS Response: CDN Edge IP 203.0.113.5
🔌 protocolDNS
🚩 flags
src198.51.100.1:53
dst192.0.2.1:53
dataDNS Response: CDN Edge IP 203.0.113.5
Client → Router 1: HTTP GET www.cdn-example.com
Router 1 → DNS Server: DNS Query www.cdn-example.com
DNS Server → Router 1: DNS Response CDN Edge IP 203.0.113.5
Router forwards DNS response to client.
Hop: 4
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromrouter1
toclient
📄 payloadDNS Response: CDN Edge IP 203.0.113.5
🔌 protocolDNS
🚩 flags
src192.0.2.1:53
dst192.0.2.10:54321
dataDNS Response: CDN Edge IP 203.0.113.5
Router 1 → DNS Server: DNS Query www.cdn-example.com
DNS Server → Router 1: DNS Response CDN Edge IP 203.0.113.5
Router 1 → Client: DNS Response CDN Edge IP 203.0.113.5
Client sends HTTP GET request to CDN edge server.
Hop: 5
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromclient
torouter1
📄 payloadHTTP GET /content.jpg
🔌 protocolHTTP
🚩 flags
src192.0.2.10:54321
dst203.0.113.5:80
dataHTTP GET /content.jpg
DNS Server → Router 1: DNS Response CDN Edge IP 203.0.113.5
Router 1 → Client: DNS Response CDN Edge IP 203.0.113.5
Client → Router 1: HTTP GET /content.jpg
Router forwards HTTP GET request to CDN edge server.
Hop: 6
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromrouter1
toedge1
📄 payloadHTTP GET /content.jpg
🔌 protocolHTTP
🚩 flags
src192.0.2.1:80
dst203.0.113.5:80
dataHTTP GET /content.jpg
Router 1 → Client: DNS Response CDN Edge IP 203.0.113.5
Client → Router 1: HTTP GET /content.jpg
Router 1 → CDN Edge Server 1: HTTP GET /content.jpg
CDN edge server performs cache lookup.
Hop: 7
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromedge1
toedge1
📄 payloadCache Lookup /content.jpg
🔌 protocolInternal
🚩 flags
src—:—
dst—:—
dataCache lookup /content.jpg
Client → Router 1: HTTP GET /content.jpg
Router 1 → CDN Edge Server 1: HTTP GET /content.jpg
CDN Edge Server 1: Cache lookup for /content.jpg
CDN edge server sends HTTP GET to origin server due to cache miss.
Hop: 8
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromedge1
torouter1
📄 payloadHTTP GET /content.jpg
🔌 protocolHTTP
🚩 flags
src203.0.113.5:80
dst198.51.100.100:80
dataHTTP GET /content.jpg
Router 1 → CDN Edge Server 1: HTTP GET /content.jpg
CDN Edge Server 1: Cache lookup for /content.jpg
CDN Edge Server 1 → Router 1: HTTP GET /content.jpg (origin request)
Origin server sends content to CDN edge server.
Hop: 9
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromorigin
torouter1
📄 payloadContent /content.jpg
🔌 protocolHTTP
🚩 flags
src198.51.100.100:80
dst203.0.113.5:80
dataContent /content.jpg
CDN Edge Server 1: Cache lookup for /content.jpg
CDN Edge Server 1 → Router 1: HTTP GET /content.jpg (origin request)
Origin Server → Router 1: Content /content.jpg
CDN edge server caches content and sends it to client.
Hop: 10
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
fromedge1
torouter1
📄 payloadContent /content.jpg
🔌 protocolHTTP
🚩 flags
src203.0.113.5:80
dst192.0.2.10:54321
dataContent /content.jpg
Origin Server → Router 1: Content /content.jpg
CDN Edge Server 1 caches /content.jpg
CDN Edge Server 1 → Router 1: Content /content.jpg (to client)
Client successfully receives content from CDN edge server.
Hop: 11
Client
DNS Server
CDN Edge Server 1
Origin Server
Router 1
📦Packet
🚩 flags
CDN Edge Server 1 caches /content.jpg
CDN Edge Server 1 → Router 1: Content /content.jpg (to client)
Router 1 → Client: Content /content.jpg received

Key Takeaways

DNS resolution directs clients to the nearest CDN edge server, enabling efficient routing.

This insight is hard to see from code alone because DNS interactions are often abstracted away, but the visualization shows the critical role of DNS in CDN operation.

Cache lookup at the CDN edge determines whether content is served quickly or fetched from the origin.

Visualizing cache hits and misses clarifies how CDNs reduce latency and origin load, which is difficult to grasp from static code.

Content delivery from the CDN edge cache significantly improves client experience by reducing network hops.

The step-by-step packet flow highlights the performance benefits of edge caching, which might be overlooked in textual explanations.

Practice

(1/5)
1. In which scenario would you most likely use CIDR notation instead of traditional classful addressing?
easy
A. When you want to efficiently allocate IP addresses to networks of varying sizes without wasting addresses
B. When you want to separate the network and host portions strictly by the first octet
C. When you need to allocate IP addresses in fixed blocks of Class A, B, or C sizes
D. When you want to assign IP addresses only within Class C networks

Solution

  1. Step 1: Understand classful addressing limitations

    Classful addressing allocates IP blocks in fixed sizes (Class A, B, C), often wasting many IP addresses.
  2. Step 2: Recognize CIDR's flexibility

    CIDR allows variable-length subnet masks, enabling allocation of IP blocks tailored to network size, reducing waste.
  3. Step 3: Evaluate options

    When you need to allocate IP addresses in fixed blocks of Class A, B, or C sizes describes classful allocation, not CIDR. When you want to separate the network and host portions strictly by the first octet is about classful fixed boundaries. When you want to assign IP addresses only within Class C networks restricts to Class C, which CIDR overcomes.
  4. Final Answer:

    Option A -> Option A
  5. Quick Check:

    CIDR is used for efficient IP allocation across variable network sizes [OK]
Hint: CIDR = flexible IP blocks, classful = fixed blocks
Common Mistakes:
  • Believing CIDR only applies to Class C networks
  • Thinking CIDR is just a different notation without functional difference
  • Assuming classful addressing is still standard for IP allocation
2. In which scenario is the IP Hash load balancing algorithm most appropriate compared to Round Robin or Least Connections?
easy
A. When you need to ensure session persistence by routing requests from the same client IP to the same server
B. When servers have highly variable processing speeds and you want to balance load evenly
C. When the number of active connections per server is constantly changing and you want to minimize response time
D. When you want to distribute requests strictly in a cyclic order regardless of client identity

Solution

  1. Step 1: Understand IP Hash purpose

    IP Hash uses the client's IP address to consistently route requests to the same backend server, enabling session persistence (sticky sessions).
  2. Step 2: Why not Round Robin or Least Connections?

    Round Robin distributes requests evenly without regard to client identity, so it does not guarantee session persistence. Least Connections balances based on current load but also does not ensure the same client hits the same server.
  3. Step 3: Match scenarios to algorithms

    When you need to ensure session persistence by routing requests from the same client IP to the same server correctly identifies the scenario where IP Hash is preferred: session persistence. Options A and C describe scenarios better suited for Least Connections or Round Robin. When you want to distribute requests strictly in a cyclic order regardless of client identity describes Round Robin behavior.
  4. Final Answer:

    Option A -> Option A
  5. Quick Check:

    IP Hash -> session stickiness; Round Robin -> cyclic distribution; Least Connections -> load-aware balancing.
Hint: IP Hash = sticky sessions by client IP
Common Mistakes:
  • Confusing Least Connections with session persistence
  • Assuming Round Robin can maintain client affinity
  • Believing IP Hash balances load evenly regardless of client IP distribution
3. Trace the sequence of events in TCP congestion control using AIMD when packet loss is detected via triple duplicate ACKs.
easy
A. Immediately stop sending data until timeout expires
B. Reset congestion window to 1 MSS and start slow start again
C. Cut congestion window to half, then increase linearly after each ACK
D. Ignore loss and continue increasing congestion window exponentially

Solution

  1. Step 1: Identify AIMD response to triple duplicate ACKs

    On triple duplicate ACKs, TCP performs fast retransmit and fast recovery, cutting congestion window to half.
  2. Step 2: Understand congestion window growth after loss

    After halving, TCP increases congestion window linearly (additive increase) to probe for available bandwidth.
  3. Step 3: Differentiate from timeout behavior

    Timeout triggers slow start (reset to 1 MSS), not triple duplicate ACKs.
  4. Step 4: Reject ignoring loss or stopping sending

    Ignoring loss or stopping immediately are incorrect TCP behaviors.
  5. Final Answer:

    Option C -> Option C
  6. Quick Check:

    Triple duplicate ACKs -> halve cwnd -> linear increase.
Hint: Triple duplicate ACKs -> fast retransmit + halve cwnd; timeout -> slow start.
Common Mistakes:
  • Confusing timeout and triple duplicate ACK loss signals
  • Assuming exponential growth continues after loss
  • Believing TCP stops sending immediately on loss
4. Why is it generally not advisable to set a fixed Retransmission Timeout (RTO) value in TCP instead of using an adaptive algorithm?
medium
A. Because fixed RTO values prevent the sender from using sequence numbers effectively
B. Because fixed RTO values increase the TCP header size, reducing throughput
C. Because fixed RTO values cause the receiver to drop out-of-order packets more frequently
D. Because a fixed RTO cannot adjust to varying network delays, leading to either premature retransmissions or long delays

Solution

  1. Step 1: Understand RTO purpose

    RTO determines when the sender retransmits unacknowledged segments, ideally matching network delay.
  2. Step 2: Analyze fixed vs adaptive RTO

    Fixed RTO cannot adapt to changing RTTs, causing retransmissions either too early (wasting bandwidth) or too late (increasing latency).
  3. Step 3: Evaluate options

    Because fixed RTO values prevent the sender from using sequence numbers effectively is incorrect; sequence number usage is unaffected by RTO. Because fixed RTO values increase the TCP header size, reducing throughput is false; RTO does not affect header size. Because fixed RTO values cause the receiver to drop out-of-order packets more frequently is unrelated to RTO. Because a fixed RTO cannot adjust to varying network delays, leading to either premature retransmissions or long delays correctly identifies the main drawback.
  4. Final Answer:

    Option D -> Option D
  5. Quick Check:

    Adaptive RTO improves efficiency by matching network conditions.
Hint: Adaptive RTO matches RTT; fixed RTO causes inefficiency.
Common Mistakes:
  • Believing fixed RTO affects TCP header size
  • Confusing RTO with receiver packet handling
  • Assuming RTO impacts sequence number usage
5. Which of the following statements about UDP is INCORRECT?
medium
A. UDP provides built-in congestion control to avoid network overload
B. UDP is connectionless and does not guarantee packet delivery
C. UDP is suitable for applications where speed is more important than reliability
D. UDP packets may arrive out of order or be duplicated

Solution

  1. Step 1: Review UDP characteristics

    UDP is connectionless, unreliable, and does not guarantee delivery or order.
  2. Step 2: Analyze congestion control

    UDP does not implement congestion control; it sends packets without adjusting to network conditions.
  3. Step 3: Evaluate options

    UDP provides built-in congestion control to avoid network overload is incorrect because UDP lacks congestion control. Options A, C, and D correctly describe UDP behavior.
  4. Final Answer:

    Option A -> Option A
  5. Quick Check:

    UDP is simple and fast but does not manage congestion.
Hint: UDP = no connection, no reliability, no congestion control.
Common Mistakes:
  • Assuming UDP has congestion control like TCP
  • Believing UDP guarantees packet order
  • Confusing connectionless with unreliable