Content Delivery Networks: Serve Content Closer to Users

Learning outcome: By the end of Day 5, you will be able to explain how a CDN serves cacheable content from an edge near the viewer, trace a cache hit and miss, and calculate how many requests still reach the origin under a simple assumption set.

This lesson is part of Korshub's System Design in 30 Days.

The beginner-friendly mental model

Use this path:

Distant origin -> nearby edge -> viewer

Your origin is the source that owns the file or response. A CDN edge location is part of a geographically distributed network positioned closer to groups of users. When the edge already has a valid copy for the request's cache key, it can return that copy directly. That is a cache hit. If it does not have a valid copy, the request is a cache miss, and the edge fetches the object from an upstream cache or the origin.

AWS documents that CloudFront routes viewer requests to a point of presence that can serve them efficiently, checks the cache, and returns a cached object when available. Cloudflare similarly defines a hit as finding the requested content in cache and a miss as needing to fetch it from the origin.

The CDN does not move your origin closer. It places reusable copies closer to viewers and routes requests to them.

Request flow

This is why a CDN can reduce both viewer latency and the number of requests the origin must answer directly. The exact performance depends on geography, routing, network conditions, object size, and cache policy.

Worked example: a Bengaluru course thumbnail

Assume:

• Ten viewers in the Bengaluru region request the same public course thumbnail.

• They produce the same cache key.

• The edge starts cold.

• The object remains present and fresh for all ten requests.

• Requests arrive sequentially, so the first fetch completes before the remaining requests.

The first request is a miss. The edge fetches the thumbnail from the origin and stores it. The next nine requests are hits.

So, under these assumptions, nine out of ten requests are served from the edge and only one fetch reaches the origin.

This is a teaching estimate, not a promised production hit rate. Real results depend on cacheability, cache-key design, freshness, eviction, traffic distribution, invalidations, and concurrent cold requests.

What controls whether an object stays cached?

HTTP response directives such as Cache-Control can tell intermediary caches how a response may be stored and for how long. A directive such as max-age provides a freshness lifetime. CDN configuration can also affect cache keys, edge TTLs, query-string handling, cookies, and headers.

The important design question is not merely "Can this be cached?" It is:

Can this exact response be safely reused for another matching request, and for how long?

Public versioned images, CSS, JavaScript, fonts, and video segments are common CDN candidates. Personalized account pages, private financial data, authorization-sensitive responses, and rapidly changing values need explicit controls and often should not be stored in a shared cache.

CDN versus an application cache

Day 4 introduced caching as a general pattern: store the result of expensive work and reuse it. A CDN applies that idea across a distributed edge network and adds request routing near users.

Neither replaces the other. A system may use a CDN at the edge, an application cache behind it, and a database as the system of record.

Try this today

Pick three responses from an application you know and classify each one:

1. Public product thumbnail.

2. User-specific shopping cart.

3. Versioned JavaScript bundle.

For each response, write:

• Is it public or private?

• Can two users safely receive the same bytes?

• What belongs in the cache key?

• How long can the object remain fresh?

• How will you update or purge it?

Completed example you can copy

Asset: /images/course-system-design-v3.webp

Classification: public, versioned static asset.

Cache-key idea: scheme + host + path; exclude irrelevant tracking query parameters only when the CDN configuration safely supports it.

Freshness idea: use a long cache lifetime because the filename changes when the bytes change.

Update strategy: publish a new filename such as v4 instead of overwriting the cached v3 object.

Privacy check: the same bytes are safe for every viewer.

The exact directives and duration must match your application's deployment and rollback strategy.

Common mistakes

1. "A CDN caches everything automatically"

Cacheability depends on the response, HTTP directives, CDN defaults, and your configuration. Dynamic or private responses should not be assumed safe.

2. "Nearest always means geographically closest"

CDNs route based on how the network can serve the request, often targeting a location with low latency. Internet routing and availability can make the best location different from the one that looks closest on a map.

3. Ignoring the cache key

Unnecessary variation from query parameters, headers, or cookies can create multiple cached objects and lower the hit rate. Removing variation carelessly can serve the wrong content. Design the key deliberately.

4. Forgetting cold or concurrent misses

The simple example assumes sequential requests. In production, several simultaneous cold requests can reach the same edge before the first fetch completes unless the CDN coordinates them.

5. Treating invalidation as an afterthought

Versioned asset names are often easier to reason about than replacing a file at the same URL and waiting for cached copies to expire.

Knowledge check

1. What is the difference between a CDN hit and a miss?

A hit is served from a valid cached object at the edge. A miss requires the edge to fetch the object from an upstream cache or origin.

2. In the ten-request example, how many requests reach the origin?

One, because the first request is the only miss under the stated assumptions.

3. Why can a CDN reduce origin load?

Because valid edge hits are returned without asking the origin to serve the object again.

4. Which is the safer shared-cache candidate: a public image or a private bank balance?

The public image. User-specific financial data requires explicit privacy and cache controls and generally should not be stored in a shared edge cache.

Continue learning with Korshub

If you want to connect CDNs with origins, routing, caching policy, reliability, and other architecture decisions, explore Software Architecture: Design of Modern Large Scale Systems.

Series navigation

• Previous: Day 4 - Caching

• Roadmap: System Design in 30 Days

• Next: Day 6 - SQL vs NoSQL