⚡Key Takeaways
- 1Caching stores frequently accessed data in fast storage to reduce latency and database load
- 2Cache hit ratio is the key metric: hits / (hits + misses). Target >90% for effective caching
- 3Cache at multiple layers: client (browser), CDN (edge), application (Redis), database (query cache)
- 4The closer the cache is to the user, the faster the response
The Power of Caching
Caching is the single most impactful performance optimization in system design. A Redis cache can serve 100K+ QPS with sub-millisecond latency, while a database might handle 10K-30K QPS at 5-50ms. Adding caching can reduce database load by 80-90%.
In system design interviews, caching comes up in virtually every problem. It's mentioned so often that interviewers sometimes say 'assume caching is in place' to move the discussion forward.
Caching Impact
Cache Layers Explained
Controlled via HTTP headers: Cache-Control: max-age=3600 (cache for 1 hour). ETag and Last-Modified enable conditional requests (304 Not Modified).
Best for: static assets (images, CSS, JS), API responses that don't change often.
Caches content at edge servers close to users. Reduces latency from ~150ms (cross-continent) to ~5-10ms (local PoP).
Best for: static files, HTML pages, streaming video, geographically distributed users.
In-memory key-value store between the application and the database. Stores computed results, session data, frequently accessed objects.
Best for: database query results, API responses, computed values (leaderboards, feed).
Database's internal cache (page cache, query cache). Automatic but limited control.
MySQL has a query cache (deprecated in 8.0). PostgreSQL uses shared_buffers for page caching.
Advantages
- •Dramatic latency reduction (50-100x)
- •Reduces database load by 80-90%
- •Enables systems to handle 10x more traffic
Disadvantages
- •Cache invalidation is notoriously hard
- •Stale data risk if not managed properly
- •Adds infrastructure complexity and cost
🧪 Test Your Understanding
What's a good target for cache hit ratio?