So far, our architecture has evolved from a single server into a horizontally scalable application:
User
↓
DNS
↓
Load Balancer
↓
Application Servers
↓
Cache / DatabaseBut there is an important problem.
If a user in India requests an image from an application server in the United States, the request may travel a long distance.
User in India
↓
│ long network distance
↓
US Application ServerThis increases:
A CDN — Content Delivery Network — can move frequently requested content closer to users.
Instead of:
User
↓
Originwe can have:
User
↓
Nearest CDN Edge
├── Cache Hit → Response
└── Cache Miss
↓
OriginThis chapter explains:
CDN stands for:
Content Delivery Network
A CDN is a geographically distributed network of servers designed to deliver content closer to end users.
Conceptually:
Origin
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Edge A Edge B Edge C
│ │ │
Users Users UsersInstead of every user contacting the origin, users can receive cached content from a nearby edge location.
An edge location is a location where CDN infrastructure is deployed close to users.
For example:
User in India
↓
India Edge
User in Europe
↓
Europe Edge
User in USA
↓
USA EdgeThe exact routing depends on the CDN.
The goal is generally:
Serve content from infrastructure that is network-close to the user.
The origin is the authoritative source from which the CDN obtains content.
For example:
CDN
↓
Origin
↓
Application / Object StorageThe origin could be:
Example:
Origin
├── HTML
├── CSS
├── JavaScript
├── Images
└── VideoSuppose the user requests:
https://example.com/logo.pngThe request is routed to a CDN edge.
User
↓
CDN Edge
↓
Cached logo.png
↓
UserThe origin is not contacted.
User
↓
CDN Edge
↓
Origin
↓
logo.png
↓
CDN Edge
↓
UserThe edge can cache the object for future requests according to the configured policy.
Without CDN:
100,000 users
↓
OriginWith CDN:
100,000 users
↓
CDN
├── 90,000 cache hits
└── 10,000 origin requestsThe origin sees far fewer requests.
This can improve:
A modern CDN can provide:
Therefore:
A CDN is a distributed edge platform, not merely a collection of cache servers.
CDNs are especially effective for static content.
Examples:
JavaScript
CSS
Images
Fonts
Videos
PDFs
DownloadsFor example:
/app.js
/styles.css
/logo.png
/font.woff2These objects can often be cached for long periods.
Dynamic content is generated based on the request or user.
Example:
GET /profileThe response might depend on:
Caching dynamic content requires much more careful design.
| Static | Dynamic |
|---|---|
| Images | Personalized profile |
| CSS | Account balance |
| JS | Private dashboard |
| Fonts | User-specific API response |
| Public videos | Real-time data |
Static content is usually easier to cache safely.
Dynamic content can also be cached, but only with appropriate cache rules.
A cache hit occurs when the requested content is already available at the edge.
Request
↓
Edge
↓
Object exists
↓
Cache HIT
↓
ResponseThis is fast because the origin does not need to process the request.
A cache miss occurs when the edge does not have a usable cached copy.
Request
↓
Edge
↓
Cache MISS
↓
Origin
↓
Object
↓
Edge stores object
↓
ResponseFuture requests may become cache hits.
A key CDN metric is:
Cache Hit Ratio
Formula:
Cache Hit Ratio =
Cache Hits / Total Cache RequestsExample:
900,000 hits
100,000 missesTotal:
1,000,000Hit ratio:
900,000 / 1,000,000
= 90%A higher hit ratio generally means less origin traffic, assuming the cached responses are appropriate.
Similarly:
Miss Ratio =
Cache Misses / Total RequestsIf:
Hit Ratio = 90%then:
Miss Ratio = 10%A low hit ratio can indicate:
TTL stands for:
Time To Live
TTL determines how long an object can remain fresh in a cache before it needs revalidation or replacement according to the caching policy.
Example:
Cache-Control: max-age=3600means the response can be considered fresh for up to 3600 seconds under the relevant HTTP caching semantics.
Static assets often benefit from long TTLs.
Example:
app.8f32a1.jsIf the filename changes whenever the content changes:
app.v1.js
app.v2.jsthen a long cache lifetime can be safer.
This pattern is called:
Cache busting / asset fingerprinting
Suppose:
app.jsis cached for one year.
You deploy a new version.
Users may still have:
old app.jsA common solution is content-based filenames:
app.a83f21.jsAfter a new build:
app.b92c11.jsThe URL changes, so the CDN can treat it as a different object.
HTTP provides cache-control directives.
Example:
Cache-Control: public, max-age=3600Other directives include:
private
no-cache
no-store
must-revalidate
s-maxageThe exact behavior depends on the caching layer and HTTP semantics.
A public response may be cacheable by shared caches.
Example:
Public homepage
Public logo
Public product imageA private response may be intended only for one user.
Example:
Account balance
Private messages
Personal dashboardNever assume that putting content behind a CDN automatically makes it safe to cache.
Caching private content incorrectly can cause data leakage.
no-store tells caches not to store the response.
This is useful for highly sensitive responses where storage in caches is not desired.
Example:
Cache-Control: no-storeUse it intentionally based on the data and caching requirements.
The name can be confusing.
no-cache does not necessarily mean:
"Never store this."
It generally means a stored response must be revalidated before reuse when the directive applies.
Therefore:
no-cache ≠ no-storeThis is a common interview trap.
There can be multiple caching layers:
User
↓
Browser Cache
↓
CDN
↓
Reverse Proxy
↓
Application Cache
↓
DatabaseEach layer has different behavior and policies.
A response may be served from:
Browserwithout making any network request.
Or:
CDNwithout reaching the origin.
A useful mental model:
User
↓
Browser Cache
↓
CDN Edge
↓
CDN Shield
↓
Reverse Proxy
↓
Application
↓
Redis
↓
DatabaseNot every system has every layer.
The principle is:
Keep frequently needed data as close to the consumer as safely possible.
A cache key determines whether two requests should use the same cached object.
A simplistic key might be:
URLFor example:
https://example.com/image.jpgBut sometimes the response depends on:
URL
+ query parameters
+ host
+ selected headers
+ cookiesThe exact cache key must match the response's variation rules.
Suppose:
/product?id=10returns Product 10.
And:
/product?id=20returns Product 20.
The query parameter must be considered appropriately in the cache key.
Otherwise:
Product 10could accidentally be served for:
Product 20Cache-key mistakes can be correctness and security bugs.
Suppose:
/image.jpg?width=100
/image.jpg?width=500If width affects the response, the cache key needs to distinguish them.
Potentially:
Key 1 → image.jpg?width=100
Key 2 → image.jpg?width=500But excessive query parameters can fragment the cache.
Therefore cache-key design is a major optimization problem.
Suppose 1 million requests use:
/product?id=10&utm_source=A
/product?id=10&utm_source=B
/product?id=10&utm_source=CIf every tracking parameter becomes part of the cache key, the CDN may store many copies of effectively identical content.
This lowers the hit ratio.
Possible solution:
Normalize irrelevant parameters before constructing the cache key.
Only do this when those parameters truly do not affect the response.
A famous caching problem is:
How do we remove stale data?
Suppose:
Product price = ₹1,000CDN caches it.
Price changes:
₹1,200The CDN may still have:
₹1,000until its TTL expires or it is invalidated.
Common strategies:
Wait until the object becomes stale.
Tell the CDN to remove a specific object.
Change the URL when content changes.
Ask the origin whether the cached representation is still valid.
Example:
Purge:
/images/product-123.jpgThe CDN removes or invalidates the object.
This can be useful when updates must propagate quickly.
However, large-scale purge operations can be expensive or operationally complex depending on the platform.
Instead of:
/logo.pnguse:
/logo.v2.pngor:
/logo.8a32fd.pngThen a new version naturally becomes a different cache object.
This is often an excellent strategy for immutable assets.
A CDN can sometimes serve stale content under carefully designed policies.
For example:
Fresh
↓
Stale
↓
RevalidateSome architectures allow serving stale content temporarily if the origin is unavailable.
This can improve availability.
But stale serving must be appropriate for the data.
Serving a stale:
blog imagemay be acceptable.
Serving stale:
account balancemay not be acceptable.
Suppose many CDN edges miss the cache at the same time.
Without shielding:
Edge A ─┐
Edge B ─┼──→ Origin
Edge C ─┤
Edge D ─┘Many requests can hit the origin.
An origin shield adds another caching layer:
Edge A ─┐
Edge B ─┼──→ Shield ──→ Origin
Edge C ─┤
Edge D ─┘The shield can consolidate requests.
Suppose a very popular object expires.
Millions of users request it simultaneously.
Object expires
↓
Many requests miss
↓
Many origin requests
↓
Origin overloadedThis is called a:
Cache stampede / thundering herd
Possible techniques include:
The goal is to prevent every request from independently rebuilding the same cache entry.
Suppose:
100 requestsall request the same missing object.
Instead of:
100 origin requeststhe CDN or cache can coordinate:
100 requests
↓
1 origin request
↓
100 responsesThis is request coalescing.
Image-heavy applications benefit significantly from CDNs.
Example:
User
↓
CDN
↓
image.jpgThe CDN can potentially provide:
Example:
Original:
4000 × 3000
Mobile:
800 × 600Generating the appropriate representation can reduce bandwidth.
Video is particularly bandwidth-intensive.
Without CDN:
Millions of users
↓
OriginThis can overwhelm origin bandwidth.
With CDN:
Users
↓
CDN Edge
↓
Cached video segmentsThe origin only needs to supply content that is not already available at the edge.
Large video files are often delivered as segments.
Conceptually:
Video
├── Segment 1
├── Segment 2
├── Segment 3
├── Segment 4
└── ...CDNs can cache these segments independently.
This is useful for adaptive streaming systems.
CDNs are not only for images.
Some APIs can also be cached.
For example:
GET /public/productsIf the response is public and changes infrequently, caching at the edge may be appropriate.
But:
GET /account/balanceshould not be casually cached in a shared CDN.
CDNs traditionally focus on content delivery.
Modern edge platforms can also execute code near users.
Instead of:
User
↓
Origin
↓
Application logicsome logic can run at the edge:
User
↓
Edge Function
↓
ResponseThis is:
Edge computing
Potential benefits:
Examples:
Redirect
A/B test assignment
Header normalization
Geo-based behavior
Bot filteringSuppose:
User from IndiaThe edge function could route:
/api
↓
India regionUser from Europe:
/api
↓
Europe regionThe routing decision happens close to the user.
A useful distinction:
Optimized for:
Optimized for:
Do not move everything to the edge.
Edge environments often have constraints such as:
Therefore edge computing is usually best for lightweight operations.
Suppose users are distributed globally:
India
Europe
USA
AustraliaWe can route users to nearby infrastructure.
India → India/Asia region
Europe → Europe region
USA → US region
Australia → Asia-Pacific regionThis can reduce network latency.
However:
Geographic proximity does not always guarantee the lowest latency.
Actual network paths, congestion, and infrastructure placement matter.
Anycast allows multiple locations to advertise the same IP address.
The network routes users toward an appropriate location according to routing policies.
Conceptually:
Same IP
├── Edge A
├── Edge B
└── Edge CUsers may reach different physical locations despite using the same destination IP.
Anycast is commonly used in global network infrastructure.
A typical CDN architecture can involve DNS:
User
↓
DNS
↓
CDN endpoint
↓
Nearest / selected edge
↓
Cache
↓
Origin if neededDNS can help direct users to the CDN infrastructure.
The CDN then handles request-level delivery.
A common architecture:
Internet
│
▼
DNS
│
▼
CDN
/ \
Cache Hit Cache Miss
│ │
▼ ▼
Client Load Balancer
│
▼
App Servers
│
▼
DatabaseThe CDN reduces the amount of traffic reaching the load balancer and application layer.
Static assets are often stored in object storage:
Client
↓
CDN
↓
Object StorageExample:
Images
Videos
PDFs
DownloadsThis can separate media delivery from application compute.
A scalable origin might be:
CDN
↓
Load Balancer
↓
App Servers
├── App 1
├── App 2
└── App 3
↓
Object Storage / DatabaseThe CDN becomes the first protection layer.
A distributed denial-of-service attack can generate huge amounts of traffic.
A CDN can absorb or filter some attacks at distributed edge locations.
Attack Traffic
↓
Distributed Edge
↓
Filtering / Mitigation
↓
OriginThe important idea is:
Do not allow all unwanted traffic to reach the origin.
CDN-based protection is only one part of a broader security architecture.
A WAF can inspect HTTP requests for suspicious patterns.
Conceptually:
User
↓
CDN
↓
WAF
↓
OriginPotential protections include:
WAF behavior must be tuned carefully to avoid blocking legitimate users.
A CDN does not automatically make an application secure.
You still need:
The CDN is one security layer.
If the origin is directly reachable from the public internet, attackers may bypass the CDN.
Example:
User
├── CDN
│ ↓
│ Origin
│
└────────────→ Direct Origin IPIf direct origin access is not intended, infrastructure can restrict origin access to trusted CDN traffic.
The exact mechanism depends on the platform.
Traffic can potentially be routed to another edge.
Cached content may continue working if policy permits.
Dynamic uncached requests may fail.
Old content may remain until TTL/revalidation.
Private or incorrect content can be served to the wrong users.
Traffic may require failover to another provider or origin path if the architecture supports it.
Caching can sometimes allow content to remain available even when the origin is temporarily unhealthy.
Example:
Origin → unavailable
Cached public content
↓
Still servedThis can improve resilience.
But availability through stale cache must be explicitly designed.
For an immutable versioned asset:
Cache-Control: public, max-age=31536000, immutableConceptually:
Versioned asset
↓
Long cache lifetimeFor a frequently changing public resource:
Cache-Control: public, max-age=60For sensitive content:
Cache-Control: private, no-storeThese are examples, not universal rules.
Suppose we have:
NextGen BlogContent:
A possible architecture:
Users
│
▼
CDN
┌─────┴─────┐
│ │
Static/Public Dynamic
│ │
▼ ▼
Cache / Edge Load Balancer
│
▼
Application Servers
│
┌───────────┼───────────┐
▼ ▼ ▼
Redis Database Object StoragePublic images and static assets can have long TTLs.
Private admin content should not be treated as public cacheable content.
Suppose:
Current hit ratio = 70%We want to improve it.
Investigate:
Are irrelevant query parameters fragmenting the cache?
Are objects expiring too quickly?
Are requests actually repetitive?
Are large objects causing eviction?
Are public responses incorrectly marked uncacheable?
Does each edge receive enough repeated traffic?
A cache has finite storage.
Suppose:
Cache capacity = 1 TBbut objects total:
10 TBThe cache must evict objects.
Common cache eviction concepts include:
CDN implementations vary.
The key idea is:
A cache cannot retain every object forever.
LRU means:
Least Recently Used
When the cache is full, remove objects that have not been accessed recently.
Conceptually:
Recently used
↑
│
A B C D E
↓
least recentLRU works well when recently accessed objects are likely to be accessed again.
LFU means:
Least Frequently Used
Remove objects with low access frequency.
This can be useful when some objects are consistently popular.
Different cache systems use different policies and optimizations.
A CDN can compress content before delivery.
Example:
Origin
↓
Large HTML
↓
CDN compression
↓
Smaller response
↓
UserCompression can reduce bandwidth and latency.
Trade-off:
CPU cost
↕
Network savingsModern CDNs commonly support modern HTTP protocols.
This can improve:
The CDN can terminate client-side HTTP/2 or HTTP/3 while using a different protocol toward the origin.
Thus:
Client
↓ HTTP/3
CDN
↓ HTTP/2 or HTTP/1.1
OriginThe exact configuration depends on the CDN and origin.
The client-facing protocol does not necessarily need to match the origin-facing protocol.
Example:
Client
↓
HTTP/3
↓
CDN
↓
HTTP/2
↓
OriginThis abstraction allows the CDN to optimize each side independently.
Suppose we know a new product page will become extremely popular at 10 AM.
Instead of waiting for the first user to cause a cache miss, we can proactively populate the cache.
Before launch
↓
Fetch popular objects
↓
CDN cache populated
↓
Traffic spike
↓
High cache-hit rateThis is called:
Cache warming / prewarming
Benefits:
Costs:
Use it when demand is sufficiently predictable.
A global system may use multiple origins:
CDN
/ \
↓ ↓
US Origin India Origin
│ │
▼ ▼
Data DataThe CDN can route misses to an appropriate origin.
This introduces additional concerns:
Multi-region data architecture will be studied later.
This distinction is important.
The delivery layer itself is unavailable.
Potential strategies:
The CDN remains available.
Cached content may still work.
CDN
├── Cache HIT → works
└── Cache MISS → origin failsThis can create partial availability.
Performance is not more important than correctness.
Bad cache:
User A's private response
↓
Shared cache
↓
User B receives User A's dataThis is a severe security failure.
Therefore always ask:
Who can receive this response?
Does the response vary by user?
Is it safe to share?
What forms part of the cache key?
How long can it remain fresh?For every CDN design, ask:
Private or rapidly changing content may be unsafe or incorrect to cache.
Routing, cache misses, network congestion, and origin latency still matter.
Incorrect keys can return incorrect content.
They have different semantics.
Updated content may remain stale.
Attackers may bypass CDN protections.
Popular objects can create huge origin spikes after expiration.
Edge environments are often intentionally constrained.
CDN caching must respect authorization and privacy boundaries.
A geographically distributed infrastructure layer that delivers content closer to users, commonly through caching and edge processing.
By serving content from an edge location closer to the user and reducing the distance to the origin.
The requested object is available in the cache and can be served without fetching it from the origin.
The cache does not have a usable copy, so the request may need to reach the origin.
The period for which a cached object can be considered fresh according to the applicable caching policy.
The process of making a cached representation no longer usable so that newer content can be fetched or revalidated.
A large number of requests simultaneously miss or revalidate the same popular object, potentially overwhelming the origin.
Investigate:
An additional caching layer that reduces the number of requests from many CDN edges directly reaching the origin.
Running selected lightweight computation closer to users rather than executing everything at a centralized origin.
Yes, if the response is safe and appropriate to cache.
Because shared caching can accidentally expose one user's data to another user.
Design a CDN architecture for a global image-sharing application.
Requirements:
100 million images
1 billion image requests/day
Global users
Low image latency
Images are mostly public
Users can replace imagesDesign:
User
↓
CDN
↓
Origin
↓
Object StorageAnswer:
Design:
Global Users
│
▼
DNS / Routing
│
▼
CDN Network
┌─────────┼─────────┐
▼ ▼ ▼
Edge A Edge B Edge C
│ │ │
└─────────┼─────────┘
▼
Origin Shield
│
▼
Load Balancer
│
┌─────────┴─────────┐
▼ ▼
App Servers Object Storage
│
▼
Cache
│
▼
DatabaseImplement/document:
When designing a CDN, think:
USERS
│
▼
ROUTING
│
▼
CDN EDGE
│
┌───────┴───────┐
│ │
HIT MISS
│ │
▼ ▼
RESPONSE ORIGIN
│
▼
DATAThen ask:
Can this response be cached?
↓
What is the cache key?
↓
How long can it remain fresh?
↓
How is it invalidated?
↓
What happens on a cache miss?
↓
Can the origin handle a miss storm?
↓
Can stale content be served safely?
↓
How is private data protected?
↓
What happens if the origin fails?
↓
What happens if the CDN fails?That is the CDN design mindset.
You should now understand:
Before moving forward, make sure you can explain:
We have now built the complete request-delivery path:
User
↓
DNS
↓
CDN
↓
Load Balancer
↓
Application Servers
↓
Cache
↓
???The ??? is one of the most important components in almost every system:
The database.
In Chapter 09, we start databases from the ground up.
We will learn:
What is a database?
↓
Why databases exist
↓
Data models
↓
Tables / Rows / Columns
↓
Keys
↓
Relationships
↓
Indexes
↓
Transactions
↓
ACID
↓
SQL vs NoSQL
↓
Database scalingWe will establish the database fundamentals before moving into SQL databases, NoSQL databases, indexing, replication, partitioning, and sharding.
Mark it as complete to track your mastery.