CDN Architecture: Content Delivery Networks

A Cricket Final, Ten Crore Screens, and One Server

Picture the final over of an India–Pakistan T20 match, streamed live on a phone app. In the last five minutes before the match starts, tens of millions of people across every state open the app within the same sixty seconds. Every one of them requests the same video stream, the same score ticker, the same team logos and ad banners. Now imagine, just for a moment, that all of this content lived on a single server sitting in a data centre in Virginia, USA, and every single request — from Kanyakumari to Kashmir — had to travel there and back before a single frame could play.

Two different problems appear here, and it is important to tell them apart because they need different fixes. The first is overload: one machine, however powerful, has a limit on how many requests per second it can process, and tens of millions of simultaneous requests will exceed that limit no matter what. The second is distance: even if that one server in Virginia never got overloaded, every request would still have to physically travel roughly 13,000 kilometres to reach it and 13,000 kilometres to come back — and that trip takes real, unavoidable time, governed by the laws of physics, not by how good the server's code is. A Content Delivery Network (CDN) is the architecture that solves both problems at once, and to understand how, we first need to understand exactly why distance costs time.

Why Distance Costs Time: The Physics of Latency

Data on the internet mostly travels as pulses of light through optical fibre. Light in a vacuum moves at 3 × 10⁸ metres per second, but glass fibre slows it down — the refractive index of the glass means light travels at roughly two-thirds of its vacuum speed inside a fibre-optic cable. That works out to approximately 200,000 kilometres per second, or a convenient 200 kilometres per millisecond.

This gives us a simple formula for the minimum possible one-way travel time of any request, called propagation delay:

time (ms) = distance (km) / 200

Let's use this on our cricket-streaming example. The great-circle distance from Mumbai to a data centre near Virginia, USA (a common location for major cloud data centres) is approximately 13,000 km.

One-way time  = 13,000 km / 200 km per ms = 65 ms
Round trip    = 65 ms x 2 = 130 ms  (request out + response back)

That 130 ms is the theoretical minimum — it assumes light travels in a perfectly straight line with zero delay anywhere else. In reality, undersea cables don't run in straight lines, and every hop through a router, switch, and server adds its own small delay. Measured round-trip times from India to a US East Coast server typically come out around 200–250 ms in practice — noticeably worse than the physics-only number, but still in the same ballpark, confirming that distance really is the dominant factor.

Now compare this to a user in Mumbai fetching the same content from a server also located in Mumbai, only 20–30 km away.

One-way time  = 25 km / 200 km per ms = 0.125 ms
Round trip    = 0.125 ms x 2 = 0.25 ms   (theoretical minimum)

Even after adding real-world overhead — DNS lookups, TCP/TLS handshakes, router processing — a same-city request typically completes in single-digit to low double-digit milliseconds, roughly 10 to 30 times faster than the trip to Virginia. This is the single most important fact in this entire chapter: you cannot make light travel faster by writing better code or buying a faster server. The only way to reduce propagation delay is to reduce the physical distance between the user and the server holding the content. That one constraint is the entire reason CDN architecture exists.

What Exactly Is a CDN?

A Content Delivery Network is a geographically distributed system of servers that keep copies of content physically close to the people requesting it, so that most requests never have to travel all the way to the original server. Two terms matter here:

• Origin server — the single authoritative server where the real, master copy of the content lives. This is where the website's owner actually uploads and updates files.
• Edge server (also called a Point of Presence, or PoP) — a server placed in a data centre closer to end users — in cities like Mumbai, Delhi, Chennai, Kolkata, Bengaluru — that stores a temporary, cached copy of content fetched from the origin.

A CDN is not a second permanent home for your data — it is a caching layer sitting in front of the origin. When it works correctly, most user requests are answered by a nearby edge server without the request ever reaching the origin at all. This is a crucial distinction from something like Google Drive or a database backup: a CDN's copies are temporary, expected to expire, and always re-derived from the origin when needed. If the origin is the single source of truth, the CDN is a network of disposable, refreshable photocopies kept near the reader.

Finding the Nearest Edge Server: Anycast Routing

Here's a question that trips up a lot of students: if there are, say, 50 edge servers around the world, how does a phone in Bengaluru know which one to talk to?

It doesn't have to know. This is handled by a networking technique called anycast. Think of a bank's national customer-care number. You dial one number from anywhere in India, but the call doesn't go to one fixed call centre — the phone network automatically routes it to whichever branch is nearest to you and currently free. You never chose the branch; the network decided for you, based on your location, using the same published number everyone else dials too.

Anycast works the same way for CDN edge servers: many physical servers around the world are configured to advertise the same IP address to the internet's routing system. When your device sends a request to that address, the internet's routing protocols (principally BGP, Border Gateway Protocol) automatically deliver it to whichever advertising server is topologically closest — normally the one requiring the fewest network hops, which in practice is usually the geographically nearest one too. You, the CBSE student, don't need to memorize BGP's internals for Grade 9 — what matters is the core idea: the same destination address quietly resolves to different physical machines depending on where the request originates.

Cache Hit, Cache Miss, and Time-To-Live (TTL)

When an edge server receives a request, it checks its local cache. Two outcomes are possible:

• Cache hit — the edge server already has a valid, unexpired copy of the requested content and serves it immediately, with no trip to the origin at all.
• Cache miss — the edge server does not have the content, or the copy it has has expired. It must fetch a fresh copy from the origin server first (paying the full distance cost), then store that copy locally before replying to the user.

How does an edge server know when a cached copy has "expired"? Every cached item is stored with a Time-To-Live (TTL) — a countdown, usually set in seconds, after which the cached copy is treated as stale and must be re-fetched from the origin on the next request. A news website's homepage image might get a long TTL (hours), because it rarely changes, while a live cricket score widget might get a TTL of just a few seconds, because it changes constantly. Setting TTL correctly is a real engineering trade-off: too long, and users might see outdated content after the origin updates; too short, and the cache barely helps because it keeps expiring and falling back to slow origin fetches.

Tracing the Cache Logic in Code

The hit/miss/TTL decision is really just one small piece of logic. Here is a simplified but fully runnable simulation of it in Python, using a plain dictionary as the cache and a simple integer "clock tick" instead of real time, so we can trace it exactly:

cache = {}  # stores {url: (content, expires_at)}

def get_content(url, current_time):
    if url in cache:
        content, expires_at = cache[url]
        if current_time < expires_at:
            return f"CACHE HIT: {content}"
    # cache miss, or the cached copy has expired
    content = f"data-for-{url}"          # pretend this came from the origin
    cache[url] = (content, current_time + 5)   # store, valid for 5 ticks
    return f"CACHE MISS -> fetched from origin: {content}"

print(get_content("/video.mp4", 0))
print(get_content("/video.mp4", 2))
print(get_content("/video.mp4", 6))

Let's trace it line by line. Call 1, current_time = 0: "/video.mp4" is not yet in cache, so we skip straight to the miss branch — we build content, store it with expires_at = 0 + 5 = 5, and print the MISS message. Call 2, current_time = 2: the URL is now in cache with expires_at = 5; since 2 < 5 is true, this is a HIT and we return immediately without touching the origin. Call 3, current_time = 6: the URL is still in cache with the same expires_at = 5, but now 6 < 5 is false — the TTL has run out, so we fall through to the miss branch again, re-fetch, and store a fresh entry with a new expiry of 6 + 5 = 11. The program prints exactly:

CACHE MISS -> fetched from origin: data-for-/video.mp4
CACHE HIT: data-for-/video.mp4
CACHE MISS -> fetched from origin: data-for-/video.mp4

Every real CDN edge server runs a far more sophisticated version of this same three-part decision — check the cache, check the expiry, decide hit or miss — across millions of URLs at once.

Worked Example: Cache Hit Ratio and Why It Matters

Engineers measure a CDN's effectiveness using the cache hit ratio:

hit ratio = hits / (hits + misses) x 100%

Suppose an edge server handling a live match stream receives 100,000 requests for the same video segment in one minute. Because the segment was requested early and cached, 92,000 of those requests are served straight from the cache, and only 8,000 arrive after the segment expired or before it was first fetched.

hit ratio = 92,000 / (92,000 + 8,000) x 100% = 92,000 / 100,000 x 100% = 92%

Now scale this up to see why it matters architecturally. Suppose across all its edge servers nationwide, a streaming platform receives 50,000,000 requests during the final over, and maintains that same 92% hit ratio.

requests reaching origin = 50,000,000 x (1 - 0.92) = 50,000,000 x 0.08 = 4,000,000

Instead of the origin server facing 5 crore simultaneous requests — which would crash almost any server — it only has to handle 40 lakh, a reduction of 92%. This is the second half of what a CDN does: it isn't only about shortening distance for each individual user, it's also about protecting the origin server from being overwhelmed in the first place, by absorbing the vast majority of repeat requests at the edge.

Push CDN vs Pull CDN

There are two architectural models for how content gets from the origin onto edge servers in the first place:

• Pull CDN — the default, lazy model used by nearly all modern general-purpose CDNs (like Amazon CloudFront or Cloudflare). Edge servers store nothing for a URL until the first real user requests it — that first request is always a cache miss, fetched from the origin and cached for everyone after. This wastes no storage on content nobody wants, but the very first visitor to any edge region always pays the full distance cost.
• Push CDN — the origin proactively uploads (pushes) content to edge servers in advance, before any user has asked for it. This avoids the "first visitor is slow" problem entirely, but requires the site operator to know in advance which content will be popular and manually manage what gets pushed where — practical for a fixed set of large files (like a big software update or a pre-scheduled video release) but wasteful for a huge library of content, most of which will never be requested at any given edge location.

Most large platforms use pull CDNs for their general content and selectively pre-push a small number of high-demand items — like the video segments for a cricket final everyone knows is coming — right before they go live.

Seeing the Architecture

The diagram shows the two paths a single request can take. The solid green line is the common case: your device is routed by anycast to the nearest edge PoP (here, Chennai), which already holds a cached, unexpired copy — a cache hit answered in roughly 8 ms. The dashed grey line is the rare case: a cache miss forces the full round trip to the origin server on another continent, costing roughly 220 ms. The dashed navy lines show origin-to-edge traffic — this is how edge servers refill their caches after a miss, keeping future requests fast again.

What a CDN Cannot Fix

Misconception 1: "A CDN makes every part of a website faster." This is false. CDNs are extremely effective for static content — video files, images, CSS and JavaScript files, downloadable PDFs — because the same bytes can be served to every user from cache. They are far less effective for dynamic, personalized content — your specific bank balance, your personalized IRCTC booking status, a live chat message meant only for you. That kind of content is different for every single request, so caching a "shared" copy for everyone makes no sense; it typically bypasses the cache entirely and must go to the origin (or a nearby application server) every time. A CDN's speed benefit applies mainly to the parts of a page that are the same for everyone, not the parts that are about you specifically.

Misconception 2: "A CDN is just extra cloud storage, like a backup." Also false, and this is worth being precise about for exams. Cloud storage (like a Google Drive or an origin server's own disk) is meant to be a durable, permanent, complete copy of your data. A CDN cache is the opposite: deliberately temporary, expected to expire via TTL, and reconstructable from the origin at any time. If every CDN edge server vanished tonight, no data would be permanently lost — the origin still holds the master copy. That is precisely why CDNs are safe to build this way: they only ever need to be "good enough, most of the time," never the sole record of anything.

One more real limitation: the very first request for a piece of content at a given edge location is always a cache miss (unless it was pre-pushed), so it is always exactly as slow as talking to the origin directly. A CDN reduces the average latency across millions of requests dramatically, but it cannot make the first visitor's very first request instant — physics still applies to that one trip.

CDNs and the Indian Internet

This chapter connects directly to networking fundamentals in the CBSE Computer Science / Informatics Practices syllabus — client-server architecture, DNS, and IP addressing — by showing what happens once those basics are combined at scale. Two India-specific pieces of infrastructure make CDN performance meaningfully better for Indian users. NIXI (National Internet Exchange of India), established in 2003, operates internet exchange points in multiple Indian cities that let domestic internet traffic be exchanged directly between Indian networks, instead of being routed out to a foreign country and back even when both the sender and receiver are within India. This kind of domestic peering is exactly what makes it possible for a CDN operator to place an edge server in, say, Chennai and have it genuinely reachable in a handful of milliseconds from anywhere in South India, rather than the traffic secretly taking a detour through Singapore or Europe. Alongside this, Indian telecom operators have invested heavily in domestic fibre backbone and undersea cable capacity over the past decade, which is part of why CDN edge locations within India have become steadily more viable and why services like large-scale cricket streaming during IPL season are possible without every request reaching a server abroad.

Common Misconceptions, Corrected

• "A more powerful server fixes slow international access." Server power affects processing time, not propagation delay caused by distance. A faster CPU cannot make light travel faster through the cable connecting Mumbai to Virginia.
• "CDN means the data now lives permanently in India (or wherever the edge server is)." No — the origin remains the single source of truth; edge copies are temporary and TTL-governed, and can vanish and be rebuilt at any time.
• "CDN speeds up everything on a website equally." No — mainly static, shared content benefits; dynamic, personalized content generally still depends on the origin or nearby application servers.

Check Your Understanding

1. A user in Kolkata sends a request to a CDN edge server 15 km away. Using 200 km/ms as the fibre propagation speed, calculate the theoretical minimum round-trip time in milliseconds.
2. An edge server logs 240,000 requests for a trending video in an hour: 216,000 are cache hits and the rest are misses. Calculate the cache hit ratio as a percentage.
3. Explain, using the idea of propagation delay, why adding a second, equally powerful origin server in the same city as the first origin server would NOT help a user in Chennai nearly as much as adding a CDN edge server in Chennai would.
4. A cached homepage banner has a TTL of 600 seconds. It was cached at t = 0. A user requests it at t = 550 and another user requests it at t = 700. For each request, state whether it is a cache hit or a cache miss, and explain why.
5. Why does a pull CDN always experience a cache miss for the very first request to any given edge location, no matter how well the CDN is engineered?
6. Distinguish, in your own words, between what an origin server stores and what an edge server stores, and why one is described as "temporary."

Summary

A Content Delivery Network exists because of one unavoidable physical fact: light in fibre-optic cable takes real, calculable time to travel real distances, and no amount of server power can shorten that time — only reducing distance can. A CDN's architecture places edge servers (PoPs) geographically close to users, so that anycast routing sends each request to the nearest one, and most requests are answered by a cached copy (a cache hit) without ever reaching the single origin server that holds the master copy. Cached copies expire according to a TTL and are refreshed from the origin on a cache miss, and CDNs can operate in a lazy pull model or a proactive push model depending on how predictable demand is. The measurable payoff is twofold: individual users get responses in single-digit milliseconds instead of hundreds, and the origin server is protected from being overwhelmed because the vast majority of repeat requests never reach it at all. What a CDN cannot do is speed up content that is different for every user, or make any first-ever request instant — those effects are governed by the same physics that motivated building CDNs in the first place.