~25 min · Foundations · Alex Xu Vol 1, Ch 1 · System Design Primer
Ref
Primary Source
System Design Primer — Caching section (github.com/donnemartin)
Excellent coverage of all caching patterns with diagrams. Also see the Redis documentation for production caching patterns.
Why Caching is the Most Important Tool
RAM is ~1000× faster than SSD and ~1,500,000× faster than a cross-continent network call. A cache puts frequently accessed data in memory so that most reads never hit the database. In most web applications, 80% of reads access only 20% of the data (the Pareto principle) — caching that 20% dramatically cuts load.
Interview impact
Adding a cache is the single most common "scale this system" answer in interviews. Always discuss it. The follow-up question will be: "What caching strategy do you use, and how do you handle invalidation?"
Cache Placement
Multiple caching layers — each saves a round trip to a slower tier
Caching Strategies
Cache-Aside (Lazy Loading) — Most Common
Flow
1. App checks cache for key
2a. Cache HIT → return value
2b. Cache MISS → app reads from DB
3. App writes result into cache
4. Return value to caller
Best for: read-heavy, data accessed more than once
Pro: Only caches what's actually needed. Con: First request always misses (cold start). On failure, app falls back to DB gracefully.
Write-Through
Flow
1. App writes to cache
2. Cache synchronously writes to DB
3. Both cache and DB are up to date
Best for: write-heavy apps where freshness matters
Pro: Cache is always fresh — no stale reads. Con: Every write hits both cache and DB → higher write latency. Infrequently read data still gets cached (wasted memory).
Write-Back (Write-Behind)
Flow
1. App writes only to cache (fast return)
2. Cache asynchronously flushes to DB
Best for: write-heavy apps where write latency is critical
Pro: Lowest write latency. Con: Risk of data loss if cache crashes before flush. Complex to implement correctly.
Read-Through
Like cache-aside, but the cache library handles the DB read automatically on a miss. The app always talks to the cache. Less common — requires a cache library that understands your data access layer.
Cache Eviction Policies
When the cache is full, something must be removed to make room. Common policies:
Policy
Evicts
Best For
LRU (Least Recently Used)
Item not accessed for the longest time
Most workloads — default choice
LFU (Least Frequently Used)
Item accessed the fewest times
When recency matters less than popularity
TTL (Time to Live)
Item that has lived past its expiry time
Time-sensitive data (sessions, trending data)
Random
Random item
Simple implementation, surprisingly effective
Cache Invalidation — The Hard Part
"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton
When the underlying data changes, stale cache entries must be invalidated. Strategies:
TTL-based expiry — entries expire after N seconds. Simple but may serve stale data up to N seconds.
Event-driven invalidation — when data changes, explicitly delete the cache key. Requires coupling between write path and cache.
Write-through — writes always update the cache, so it's never stale.
Cache-aside with short TTL — pragmatic: short TTL limits staleness, cache-aside prevents wasted writes.
CDN — Cache at the Edge
A CDN (Content Delivery Network) caches static content at edge servers geographically close to users. A user in Tokyo hitting your US server adds 150ms. A CDN edge in Tokyo adds 5ms. For images, video, CSS, and JS — always use a CDN.
💡 Interview tip
"I'll put a CDN in front for static assets. For dynamic API responses, I'll use Redis with a 60-second TTL for the feed, and cache-aside for user profile reads. Profile writes will invalidate the cache key immediately."
Check Your Understanding
1. A user updates their profile photo. Your app uses cache-aside. What must you do to prevent other users from seeing the old photo?
2. Write-back caching offers the fastest write latency. What's the key risk?
3. Your news feed shows posts from the last 24 hours. Which eviction policy fits best?
🎓 Caching shows up everywhere. Ask me about the thundering herd problem (when your cache expires and 10,000 requests simultaneously hit the DB), or how distributed caches handle node failures, or the difference between Redis and Memcached.