CDN Request Routing: Anycast, GeoDNS, and the Latency-Bandwidth Trade-off

The Routing Challenge 📍

When Upintha requests a video, how does her request reach the nearest CDN server among 10 million distributed servers worldwide?

Method 1: GeoDNS (Geographic DNS)

How it works:

DNS knows Upintha's geographic location (via IP address)
DNS knows CDN server locations
DNS returns the IP address of the nearest edge server automatically

Limitation: Few DNS providers offer GeoDNS functionality, so CDNs cannot rely on this approach alone.

Method 2: Anycast with Origin Server Redirect (Standard Approach)

The Flow

Step 1: Upintha's request goes to the CDN's primary origin server (load balancer)

Step 2: Origin server doesn't serve the file directly. Instead, it redirects Upintha to the nearest edge node:

Upintha → CDN Origin: "Give me video.mp4"

CDN Origin → Upintha: "I can serve it, but bandwidth will be low. 
                       Request it from edge-us-west.cdn.com instead."

Upintha → Edge Node: "Give me video.mp4"

Edge Node → Upintha: [serves file with high bandwidth]

The Trade-off

Latency: Increases slightly (extra redirect hop)

Bandwidth: Increases significantly (large file transfer from nearby server)

For large files, bandwidth matters more than latency, making this trade-off worthwhile.

Latency vs. Bandwidth: The Numbers ⚖️

Scenario: Serve from Origin (Bad)

Latency: 10 ms
Bandwidth: 1 Mbps (far away, low bandwidth)
File size: 10 MB

Download time: 10 seconds
Total time: 10.01 seconds

Scenario: Redirect to Edge Node (Good)

Latency: 110 ms (extra 100ms for redirect)
Bandwidth: 10 Mbps (nearby edge node, high bandwidth)
File size: 10 MB

Download time: 1 second
Total time: 1.11 seconds

Conclusion: Despite higher latency, the edge node approach is 9x faster because of superior bandwidth.

IP-Based Geolocation 🌐

Question: How does the origin server know Upintha's location?

Answer: Your IP address reveals your geolocation with ~1 kilometer accuracy.

The CDN can pinpoint users based on IP and route them to the nearest edge server. No additional geolocation service needed.

Anycast Technology Explained 🔀

What is Anycast?

The main CDN server acts as a delegator (like a manager in a company):

User request arrives at main CDN server
Main server redirects (doesn't proxy) to the nearest edge node
User fetches file directly from edge node

Difference from Load Balancer

Load Balancer:

Request → LB → Server → LB → User

(Round trip through load balancer)

Anycast CDN:

Request → Origin → Redirect response → Edge → User

(Direct return from edge node)

The load balancer proxies all traffic. Anycast simply redirects once, then gets out of the way.

Edge Server Independence 🔒

Question: Do CDN edge servers share cached data with each other?

Answer: No. Each edge server operates independently (like a local cache).

Behavior

Edge Server A caches a file
Edge Server B does not automatically receive the cached file
Edge Server B will cache it only when a user requests it from that server

Storage: Edge servers cache data on disk (not just RAM) because they need to store large amounts of content persistently.

Fault Tolerance

CDN servers do not use master-slave replication. If an edge server crashes:

User requests route to a different edge server
That server fetches from the origin database
No data is permanently lost (database is the source of truth)

The Two-Request Rule ⚡

Important: Every CDN request involves two steps:

DNS lookup → Returns origin server IP
Origin redirect → Returns edge node IP
Edge fetch → Delivers actual file

This happens on every request, not just the first one. It's a shortcoming of Anycast that adds latency, but the bandwidth gain outweighs this cost.

Next: Backend caching strategies global vs. local cache architectures.