Hi Pythonistas!
Your server is in Mumbai.User is in New York.They request your website.HTML loads.
Then:
- 10 images to load
- 5 CSS files
- 8 JavaScript files
- 3 fonts
Every file round trip to Mumbai.
New York → Mumbai → New York
Distance: ~13,000 km
Round trip time: ~130ms minimum
Just for physics.
Before any server processing.26 files × 130ms = 3.38 seconds just in network time.User is waiting 3+ seconds.Not because your server is slow.Because of distance.
The Idea
What if you could put copies of your files closer to your users?
User in New York → files from New York.
User in London → files from London.
User in Kerala → files from Chennai.
No long distance travel.
Files served from the nearest location.That's a CDN - Content Delivery Network.A globally distributed network of servers
that cache and serve your content from locations close to your users.
How CDN Works
CDN providers have Points of Presence (PoPs) worldwide.Each PoP = a data center with servers.
Cloudflare alone has 300+ PoPs across the globe.
New York PoP
London PoP
Mumbai PoP
Singapore PoP
São Paulo PoP
...300+ more
These servers are called edge servers.They sit at the edge of the network. Close to users.Far from your origin.
The Request Flow
First user to request a file:
User in New York
↓
Requests image.png
↓
DNS → nearest CDN edge (New York PoP)
↓
Edge server: "I don't have this" ❌
↓
Fetches from your origin server (Mumbai)
↓
Caches the file
↓
Serves to user
Cache miss at CDN level.Slow this first time.
Every user after:
User in New York
↓
Requests image.png
↓
DNS → New York PoP
↓
Edge server: "I have this" ✅
↓
Serves immediately from local cache
~5ms instead of ~130ms.
26x faster.
No trip to Mumbai.
How DNS Routes You to the Nearest PoP Same domain name. Different IP for different users.
When you request cdn.parseltongue.co.in:
CDN's DNS checks your location.
Returns IP of nearest PoP.
User in New York → New York PoP IP
User in Kerala → Mumbai PoP IP
User in London → London PoP IP
This is called GeoDNS or Anycast routing.One domain.Hundreds of locations.Nearest one wins.
What CDN Caches
CDN is designed for static content.
Files that don't change per user.
Images → .jpg, .png, .webp
CSS → stylesheets
JavaScript → frontend code
Fonts → .woff, .woff2
Videos → .mp4, .webm
Documents → .pdf
Not suitable for:
User-specific data → your profile page
Real-time data → live scores
Personalized content → recommendations
Although modern CDNs are pushing this boundary.
More on that soon.
CDN TTL and Cache Control
CDN respects your cache headers.
You control how long it caches your files.
Cache-Control: max-age=86400
CDN caches for 86400 seconds (24 hours).
After that → fetches fresh copy from origin.
Different TTLs for different content:
Images (rarely change): max-age=2592000 (30 days)
CSS/JS (versioned): max-age=31536000 (1 year)
HTML (changes often): max-age=300 (5 minutes)
API responses: no-cache (don't cache)
Cache Busting
You deploy new CSS.CDN still serves old cached CSS for 1 year.Users get broken layout.
Solution: cache busting.Include a version hash in the filename:
Before: styles.css
After: styles.a3f2b1.css
New deployment → new hash → new filename.CDN has never seen this filename.
Cache miss → fetches new file → caches it.
Old file URL never requested again.
This is why you see filenames like:
main.8f3a2b1c.js
styles.d4e5f6a7.css
In production builds.
webpack, Vite, Next.js do this automatically.
CDN for Dynamic Content
Traditional CDN = static files only.
Modern CDN = much more.
Edge computing:
Run code at edge servers.
Instead of:
User → CDN edge → Origin server (dynamic logic)
Now:
User → CDN edge (runs your code here) → Done
No trip to origin.
Examples:
Cloudflare Workers → JavaScript at edge
AWS Lambda@Edge → Lambda functions at edge
Vercel Edge Runtime → Next.js at edge
Use cases:
A/B testing → different response per user
Authentication → verify JWT at edge
Personalization → modify HTML based on location
Bot detection → filter bots before origin
CDN Providers
- Cloudflare: Most popular, 300+ PoPs, Free tier available, DDoS protection built in, Used by: Discord, Canva.
- AWS CloudFront: Tight AWS integration, Best if you're already on AWS, Used by: Netflix, Amazon.
- Fastly: Developer-friendly, Instant cache purging (< 150ms globally), Used by: GitHub, Reddit, Stripe.
- Akamai: Oldest. Most enterprise, 170,000+ servers, Used by: banks, governments.
CDN and Origin Shielding
Your origin server = your actual server.CDN sits in front.Origin never exposed directly.
parseltongue.co.in → points to Cloudflare
Cloudflare proxies → your actual server
Your real server IP → hidden
Attacker tries to DDoS your server they hit Cloudflare first.Cloudflare absorbs it.Your server never sees the attack.This is called origin shielding.
CDN in Your System
CDN fits into your system like this:
User
↓
DNS → nearest CDN PoP
↓
CDN edge server
↓
Cache hit? → serve immediately ← most requests end here
Cache miss?
↓
Origin Load Balancer
↓
App Servers
↓
Redis Cache
↓
Database
Most requests never reach your origin.
CDN absorbs the traffic.
CDN also gives you:
DDoS protection → absorbs attacks at edge
SSL termination → handles HTTPS at edge
HTTP/3 support → automatic
Compression → gzip/brotli automatically
Image optimization → resize, convert to WebP
Mental Model
CDN → globally distributed cache for static files
PoP → Point of Presence, CDN's edge data center
Edge server → CDN server close to users
Origin → your actual server
Cache hit → file served from edge, fast
Cache miss → edge fetches from origin, caches it
GeoDNS → routes user to nearest PoP
Anycast → same IP, multiple locations, nearest wins
TTL → how long CDN caches your file
Cache busting → new filename forces CDN to fetch fresh
Edge computing → run code at CDN edge, no origin trip
Origin shielding → CDN hides your real server IP
What's Coming Next
Now your system has:
- multiple servers.
- load balancing.
- caching.
- CDN for static files.
But your database is still one machine.Everything hits it.It's the bottleneck.
How do you scale the database? Database Sharding and Partitioning.
