We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Web & Content Delivery
The process of distributing and serving content to users from locations geographically close to them for faster load times.
In short
Content delivery is the practice of serving a website's files, images, video, and API responses from servers placed physically close to each user instead of from one origin server, so the data travels a shorter distance and arrives faster. It is what makes a site loaded from London feel just as fast in Sydney, and it is delivered mostly through caching networks called CDNs.
In short
Content delivery is the practice of serving a website's files, images, video, and API responses from servers placed physically close to each user instead of from one origin server, so the data travels a shorter distance and arrives faster. It is what makes a site loaded from London feel just as fast in Sydney, and it is delivered mostly through caching networks called CDNs.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Content Delivery across a run of lessons, not one page. These 3 alone are about 109 minutes of step-by-step reading, every one with a quiz.
A CDN is thousands of caches you do not operate, and the cache key decides everything about whether it helps you.
Design a CDN from scratch - edge caching, origin shield, cache purging, anycast routing, TLS termination, and global distribution.
Serving personalized, real-time, or user-specific content that cannot be pre-built or cached uniformly.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Content Delivery Network (CDN)pay once,
yours for life
When you load a web page, your browser pulls down dozens of separate things: HTML, CSS, JavaScript bundles, fonts, images, maybe a video stream, and the data behind it all. Content delivery is the discipline of getting every one of those things to the user as quickly and reliably as possible, no matter where in the world they are sitting.
The core problem is distance. Data cannot travel faster than light through fiber, so a request from Sydney to a server in Virginia has to cross roughly 16,000 km each way. Even at ideal speed that is about 80 ms of pure travel before the server does any work, and real networks add much more. If every user hit one origin server, far-away users would always feel a lag.
The fix is to keep copies of the content in many places at once. Instead of one server in one city, you put hundreds of edge servers in cities around the world and serve each user from the closest one. A user in Sydney gets the file from a Sydney edge server in a few milliseconds rather than waiting for a round trip across the Pacific.
Most content delivery runs through a CDN (Content Delivery Network), a fleet of edge servers spread across hundreds of points of presence. Cloudflare, for example, runs in more than 300 cities. Each edge server is a caching proxy that sits in front of your origin.
The flow is simple. The first time a user in a region requests a file, the nearest edge server does not have it yet, so it fetches the file from the origin once, stores a copy, and returns it. This is a cache miss. Every later request from that region is served straight from the edge copy without touching the origin. This is a cache hit, and a good setup serves 90 percent or more of traffic this way.
Routing the user to the right edge server is usually done with anycast or DNS. With anycast, the same IP address is announced from every location and the internet's own routing naturally sends the user to the nearest one. Cache freshness is controlled with the Cache-Control header and a TTL (time to live); when the TTL expires the edge revalidates with the origin. Static assets like images and JS bundles cache for hours or days, while dynamic API responses cache for seconds or not at all.
Content delivery is worth it the moment you have users in more than one region or you serve large static files. It cuts latency, absorbs traffic spikes, reduces load on your origin servers, and provides a layer that blocks DDoS attacks before they reach you. For media-heavy products it is not optional; streaming a movie from a single origin to millions of viewers would melt the origin and saturate its uplink.
The main trade-off is staleness. Because the edge serves cached copies, a user can see an old version of a file after you have updated the origin. The standard fix is cache invalidation, either by setting short TTLs or by giving each file a unique versioned name like app.4f9c2.js so a new deploy is a brand new file that no edge has cached yet.
The other costs are money and complexity. CDNs bill per gigabyte transferred and per request, which adds up for high-traffic video. Caching dynamic or personalized content is also tricky, because a page that shows your name must not be served to someone else, so you cache the shared parts and leave the personal parts uncached or fetched separately.
Picture a software company in Virginia whose origin server holds a 2 MB JavaScript bundle. A user opens the site in Tokyo. The Tokyo edge server has no copy yet, so it fetches the bundle once across the Pacific, a slow round trip of maybe 150 ms. It stores the file and serves it to the user.
Over the next hour, ten thousand more users in Japan load the same site. Every one of them gets the bundle from the Tokyo edge over a round trip of under 20 ms, and the origin in Virginia never hears about any of them. The company's origin handled one request instead of ten thousand and one, and Japanese users got a fast site despite the origin being on the other side of the planet.
When the company ships a new version, it renames the bundle to app.v2.js. The old cached copies are now irrelevant and the edges fetch the new file on first request, so every user gets the update with no manual cache purge. That single pattern, edge caching plus versioned filenames, is the backbone of how the modern web stays fast.
Cloudflare
Runs edge servers in 300-plus cities and serves cached content plus DDoS protection in front of millions of websites.
Amazon CloudFront
AWS's CDN with 600-plus points of presence; pulls from S3 or any origin and is the default delivery layer for many AWS-hosted apps.
Netflix Open Connect
Places its own caching appliances directly inside ISP networks so popular shows stream from a box a few hops from the viewer.
Akamai
One of the oldest CDNs, with hundreds of thousands of edge servers delivering software updates, video, and web assets for large enterprises.
Content delivery is the goal: getting content to users fast and reliably. A CDN is the most common tool that achieves it, a network of edge servers that cache copies of your content close to users. You can do basic content delivery without a CDN, for example by running your own regional servers, but a CDN is the standard turnkey solution.
By default it caches only what you tell it to via Cache-Control headers, and you usually mark personalized or per-user responses as no-cache so they are never shared. The common pattern is to cache the static, shared parts of a page heavily and fetch the personal parts separately, often through an uncached API call.
Most CDNs use anycast routing, where every edge location announces the same IP address and the internet's routing automatically sends traffic to the topologically closest one. Some use DNS-based routing instead, returning a different edge IP depending on where the DNS query came from.
That is a stale cache. You fix it either by setting a short TTL so the edge revalidates with your origin frequently, by issuing a cache purge or invalidation request to the CDN, or, best of all, by giving each new build a unique filename so an update is a brand new file no edge has cached yet.
No. Static assets like images, CSS, JS, and video are the easiest wins because they rarely change, but modern CDNs also cache API responses for short windows, run code at the edge for dynamic logic, and proxy and protect even fully dynamic traffic that they never cache.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Edge Computing
Running computation at the network edge, close to the user, instead of in a central data center. Reduces latency for real-time applications like IoT and streaming.
HTTP Caching
Browser and proxy caching controlled by HTTP headers like Cache-Control, ETag, and Last-Modified. Eliminates redundant network requests for unchanged resources.
Static Site Generation (SSG)
Pre-rendering pages to static HTML at build time. The fastest possible page loads because there's no server-side computation on each request.
This page explains the idea. The "Content Delivery Network (CDN)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Content Delivery Network (CDN) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Content Delivery in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
