Caching

The single most effective way to scale a system. Learn the patterns (Write-Through vs Write-Back), the Eviction policies, and the dangers of the Thundering Herd.

What you will learn

• Understand the 5 Layers of Caching (Browser -> Edge -> API -> App -> DB)
• Master the 3 Strategies: Cache-Aside, Write-Through, Write-Back
• Solve the Thundering Herd problem with Jitter
• Choose the right Eviction Policy (LRU vs LFU)

Caching shows up in almost every system design interview because it improves latency, lowers infrastructure cost, and protects downstream systems from repeated work. Interviewers care less about whether you know Redis exists and more about whether you understand when caching helps, when it becomes dangerous, and how it fails.

Caching is a bet that future requests will look enough like recent requests that storing a fast copy is worth the complexity. Every cache is really an exchange: you accept some staleness and invalidation complexity in return for better speed and lower load.

The central tradeoff is freshness versus performance. The more aggressively you cache, the faster and cheaper reads become. The cost is that invalidation, consistency, and hot-key behavior become harder to manage.

WARNING: Teams often treat caching as a free speed boost and only later discover stale data, cache stampedes, or write-path inconsistency. A cache is not just a performance layer. It changes correctness behavior too.

Create a free account to read the full chapter — advanced chapters, progress tracking, and quizzes are free with sign-up.