Courses 0%
35
Caching Fundamentals · Chapter 35 of 42

Server Cache & Browser Cache

Akhil
Akhil Sharma
20 min

Browser Cache vs Server Cache - The Complete Picture

🎯 Challenge 5: The Coffee Shop Chain

Scenario: You're running a coffee shop chain:

Storage Option A: Customer's Pocket

  • Customer buys coffee, keeps cup for refill
  • Next visit: Instant refill (they bring their own cup!)
  • Fast but limited (only that customer's drink)

Storage Option B: Shop Counter

  • Shop keeps popular drinks ready
  • Any customer: Quick serve from counter
  • Medium speed, benefits multiple customers

Storage Option C: Central Warehouse

  • All coffee beans stored centrally
  • Any shop can request
  • Slower, but serves all shops

Question: Which layer serves which purpose? Can you use all three?

The Answer: Multi-Layer Caching!

Browser Cache = Customer's pocket (local storage) Server Cache = Shop counter (shared cache) Database = Warehouse (source of truth)


🎯 Browser Cache: Your Personal Storage

What is it?

  • Storage on YOUR computer/phone
  • Managed by YOUR browser
  • Only YOU can access it
  • Fastest possible cache!

What gets cached:

✅ Images (.jpg, .png, .gif) ✅ Stylesheets (.css) ✅ JavaScript (.js) ✅ Fonts (.woff, .ttf) ✅ HTML pages ✅ Videos (partial) ✅ API responses (if configured)


How browser cache works:

First visit to website:

Browser → "Give me style.css" → Server Server → "Here's style.css (Cache for 1 day)" → Browser Browser saves locally ✓

Second visit (within 1 day):

Browser → Check local cache → style.css found! ✓ (No server request needed!) Load instantly ⚡

After 1 day (expired):

Browser → Check local cache → Expired! Browser → "Is style.css still current?" → Server Server → "Yes, use cached version" → Browser (304 Not Modified) OR Server → "New version available" → Browser (200 + new file)


Browser cache locations:

bash

Size limits:

  • Chrome: ~10% of disk space

  • Firefox: ~1 GB (configurable)

  • Safari: No fixed limit


Controlling browser cache:

html
js

🖥️ Server Cache: Shared Speed Boost

What is it?

  • Storage on SERVER (Redis, Memcached)
  • Shared by ALL users
  • Faster than database
  • Controlled by developers

What gets cached:

✅ Database query results

✅ API responses

✅ Session data

✅ Computed values

✅ User profiles

✅ Product listings

✅ HTML fragments


Server cache architecture:

img1

Flow:

js

📊 Browser vs Server Cache Comparison

AspectBrowser CacheServer Cache
LocationClient deviceServer/Cloud
ScopeSingle userAll users
SpeedFastest (local)Very fast (in-memory)
SizeLimited (MB-GB)Large (GB-TB)
ControlHTTP headersFull control
PersistenceUntil clearedUntil evicted
SecurityCan be inspectedSecure
CostFree (user's device)Costs money

🎪 Real-World Example: Loading a Web Page

Complete caching flow:

User visits https://mysite.com/products

img2

TOTAL PAGE LOAD:

  • Best case (all cached): 10-20ms ⚡⚡⚡
  • Worst case (nothing cached): 100-200ms ⏱️

🛠️ Complete Implementation Example

Browser + Server + CDN caching:

SERVER SIDE (Node.js + Express + Redis)

js

Benefits:

  • Offline support (works without internet!)
  • Custom caching strategies
  • Background sync
  • Push notifications

💡 Best Practices Summary

✅ DO:

  • Use browser cache for static assets (1 year TTL)
  • Use server cache for database queries
  • Use CDN for global content delivery
  • Version your assets (cache busting)
  • Set appropriate TTLs based on data type
  • Monitor cache hit ratios
  • Test cache behavior thoroughly

❌ DON'T:

  • Cache user-specific data in CDN
  • Cache sensitive data in browser
  • Set TTL too high for dynamic content
  • Forget to invalidate on updates
  • Cache everything (be selective!)
  • Ignore cache headers

🎓 Complete System: All Caching Layers Together

Production architecture with all caching:

img3

Performance results:

1000 requests:

├─ 700 served by browser cache (0ms each) = 0 seconds

├─ 200 served by CDN cache (20ms each) = 4 seconds

├─ 80 served by server cache (5ms each) = 0.4 seconds

└─ 20 served by database (100ms each) = 2 seconds

Total time: 6.4 seconds for 1000 requests Average: 6.4ms per request ⚡

Without caching: 1000 requests × 100ms = 100 seconds ⏱️ (15x slower!)


🏆 Final Knowledge Check

Without looking back, can you explain:

  1. What is caching and why is it faster?

  2. What's the difference between cache hit and cache miss? Which is better?

  3. Describe LRU eviction policy. When would you use it?

  4. What does a CDN do and how does it improve speed?

  5. Where is browser cache stored? Where is server cache stored? Which is faster?


Answers:

  1. Caching stores frequently accessed data in fast storage (memory) instead of slow storage (disk/network). It's faster because memory access takes nanoseconds while disk/network takes milliseconds - a 1000-10,000x difference!

  2. Cache hit = data found in cache (fast). Cache miss = data not in cache, must fetch from source (slow). Hits are better! High hit ratio (85%+) means your cache is working well.

  3. LRU removes the least recently used item. Mental model: If you haven't used it recently, you probably won't need it soon. Use LRU for general-purpose caching - it's the best balance of performance and simplicity for most workloads.

  4. CDN stores copies of content on servers worldwide, close to users. Instead of everyone accessing your US server from Tokyo (150ms), they access a Tokyo CDN server (10ms) - 15x faster! Also saves bandwidth.

  5. Browser cache: On user's device (C:\Users...\Cache). Server cache: On server/cloud (Redis/Memcached in RAM). Browser cache is faster for that user (local), but server cache helps all users!


🚀 Your Next Caching Adventures

Master these fundamentals, then explore:

Immediate Next Steps:

  • Cache invalidation strategies (the "hardest problem")
  • Redis in-depth (data structures, pub/sub)
  • Cache-aside vs Write-through vs Write-behind patterns
  • HTTP caching headers deep dive

Advanced Topics:

  • Distributed caching (cache consistency)
  • Multi-level cache hierarchies
  • Cache warming and preloading
  • A/B testing with caching
  • Edge computing (Cloudflare Workers, Lambda@Edge)

Practical Projects:

  • Build a caching proxy server
  • Implement LRU cache from scratch
  • Set up multi-region CDN
  • Monitor and optimize cache hit ratios
  • Design caching strategy for real app

Remember: Caching is the #1 way to make applications faster! Master these concepts and you'll be able to make any system lightning-fast! ⚡💪


🎓 You've now mastered:

✅ What caching is and why it matters

✅ Cache hits vs misses

✅ Eviction policies (LRU, LFU, FIFO)

✅ CDN fundamentals

✅ Browser vs Server caching

Congratulations! You understand how the entire internet stays fast! 🎉


Key Takeaways

  1. Browser cache is the fastest cache layer — zero network latency, but limited to a single user
  2. Server-side caches (Redis, Memcached) are shared across all users — one cache entry serves thousands of requests
  3. Cache-Control headers control browser caching behavior — max-age, no-cache, no-store, and ETag serve different purposes
  4. Service workers enable offline caching in the browser — critical for progressive web apps and unreliable network conditions
Chapter complete!

Course Complete!

You've finished all 42 chapters of

Introduction to System Design

Browse courses
Up next High Level and Low Level Design
Continue