Content Delivery Networks
Adda's image-heavy posts crawl for users far from Dhaka. Ria and Tanvir can't move Dhaka closer to Sydney — so they move the content instead, with copies at the edge.
The problem
Adda's servers live in Dhaka. Adda's users, increasingly, do not. Posts have gotten image-heavy — people share photos, memes, screenshots — and every one of those images is served from that single origin. A user in Sydney opens a popular post, and every byte of the image crawls thousands of kilometers across the ocean and back. The image is fine; the distance is the problem. This is the latency tax Ria learned about when Fahim's cousin complained — now it's showing up at scale.
Tanvir points out it gets worse under load. When a post goes big and thousands of far-away users all pull the same large image from that one Dhaka origin, it saturates the origin's outbound bandwidth and stacks a fat speed-of-light delay on top. Everyone far away has a bad time, and the origin strains to push the same bytes over and over. They cannot move Sydney closer — so they must move the content.
A first attempt
The obvious fix, and the one they already know is wrong: buy a bigger server and a fatter pipe in Dhaka.
But this is a latency problem, not a bandwidth one, and no upgrade in Dhaka shortens the road to Sydney. A Sydney↔Dhaka round trip is a couple hundred milliseconds set by the speed of light — untouchable from Dhaka. Meanwhile the same image bytes are shipped across the ocean thousands of times because nothing near the user remembers them. Scaling up one location cannot fix a problem caused by distance. Adda needs presence in many locations at once.
The insight
Keep copies of your content in many locations worldwide, and serve each user from the one nearest them.
That network of geographically distributed cache servers is a CDN. Tanvir puts copies of Adda's images on edge servers in Sydney, Frankfurt, São Paulo, Tokyo — hundreds of cities. Now the Sydney user's request travels a few dozen kilometers, not across an ocean. The edge caches the content on first request and serves everyone else locally. Adda attacks latency by collapsing distance, and shields its origin because the edge answers most requests without ever touching Dhaka.
How it works
DNS sends users to the nearest edge
When a user resolves Adda's CDN hostname, the CDN's DNS returns the IP of the closest, healthiest edge location (by geography/network path). The user connects to an edge a few milliseconds away instead of the distant Dhaka origin.
Cache hit — served locally
If that edge already has the image cached, it returns it immediately. No trip to the origin. This is the fast path and, for static content like Adda's photos, the overwhelming majority of requests.
Cache miss — fetch once from origin
On the first request (or after expiry), the edge fetches the file from Adda's origin, stores it locally with a TTL, and serves it. The next user in that region gets a hit. One origin fetch serves a whole region.
Expiry and invalidation
Cached objects carry a TTL (via Cache-Control). When it expires the edge re-validates with the origin. When Adda changes a file before expiry, the team issues a purge/invalidation or changes the URL (app.v2.js, or a content hash) to force fresh fetches.
Same request, without and with a CDN:
The numbers
What the edge bought Adda:
- Latency win: a far-away static asset drops from ~150–250 ms (cross-ocean origin) to ~5–30 ms (local edge) — often a 5–10× improvement.
- Cache hit ratio: a well-tuned CDN serves 85–99% of static requests from the edge, so Adda's origin sees only the misses.
- Origin offload: at a 95% hit ratio, the Dhaka origin handles 1 in 20 requests — a 20× traffic reduction and matching bandwidth savings.
- Scale: major CDNs run hundreds of PoPs across the globe, so almost every Adda user is within ~50 ms of an edge.
- TTL tuning: static assets (images, CSS, JS) get long TTLs (hours–days); frequently changing pages get short TTLs (seconds–minutes) or are cached only after careful invalidation planning.
Static is easy, dynamic is the hard part
CDNs shine on static content — images, video, CSS/JS, fonts — that is identical for everyone and safe to cache long. Dynamic, per-user content (a user's own feed, their account page) is risky to cache: serve it to the wrong user and you leak their data. Options are short TTLs, caching only the static shell, or edge compute — but "just cache everything" is how Adda would ship one user's data to another.
Cache invalidation is the catch
Copies scattered across hundreds of edges are wonderful until you need to change one. Nothing updates instantly — you either wait out the TTL, issue a global purge (seconds to minutes to propagate), or sidestep it entirely with versioned/hashed URLs so new content simply has a new address. Plan how you will invalidate before you cache.
Practice
Recap
- A CDN keeps copies of content at edge servers worldwide and serves each user from the nearest one, attacking latency by collapsing distance — Adda's fix for far-away, image-heavy posts.
- Cache hits serve locally in milliseconds; misses fetch once from origin — yielding both a big latency win and heavy origin offload.
- CDNs excel at static content; dynamic/personalized content and cache invalidation are the genuine hard parts — plan versioning and TTLs deliberately.
Latency vs Bandwidth
Why distance-driven latency is the problem a CDN solves.
DNS: The Internet's Phone Book
How users get steered to the nearest edge.
Caching Fundamentals
The hits, misses, TTLs, and invalidation behind every edge.
In an interview
Whenever a system has a global audience or serves heavy static assets, propose a CDN early and justify it as a latency fix (distance) plus origin offload. Score extra points by volunteering the hard part unprompted: how you will handle cache invalidation (versioned URLs) and what you will not cache (per-user dynamic content).
How is this guide?
Last updated on
Load Balancing
Adda goes viral in Fahim's university and the laptop under the desk pins at 100%. Ria hires Tanvir, and together they put a traffic cop in front of a fleet that keeps everyone busy but no one overwhelmed.
Caching Fundamentals
Adda's database is melting under a flood of identical reads for the same hot posts. Ria and Tanvir stop re-answering the same question — they answer it once and remember the answer.