3.5. Distributed Caching
A cache trades correctness for speed: it serves stale data fast to spare an expensive backend. That trade is almost always worth it and almost always underestimated, because the hard part is not the hit — it is invalidation, and the failure modes when the cache itself becomes a bottleneck or a thundering-herd amplifier. This chapter covers the caching strategies, invalidation approaches, Redis cluster architecture, and the stampede-prevention techniques that keep a cache miss from becoming an outage.
Topics Covered
Section titled “Topics Covered”- 3.5.1. Cache Strategies: Cache-Aside, Read-Through, Write-Through, Write-Behind: Compares cache-aside, read-through, write-through, and write-behind strategies and their consistency implications.
- 3.5.2. Cache Invalidation: TTL, Event-Based, and Versioned Keys: Covers TTL, event-based, and versioned-key invalidation, and why invalidation is the hard part of caching.
- 3.5.3. Redis Cluster Architecture: Sharding, Replication, Sentinel: Explains Redis Cluster sharding, replication, and Sentinel-based failover for a highly available cache.
- 3.5.4. Cache Stampede and Thundering Herd: Prevention Techniques: Covers cache stampede and thundering herd, and prevention via locking, coalescing, and early expiration.
- 3.5.5. Distributed vs. Local Cache: Consistency Trade-offs: Weighs the consistency and latency trade-offs between a shared distributed cache and per-node local caches.
- 3.5.6. Memcached vs. Redis: Architectural Comparison: Compares Memcached’s simplicity against Redis’s data structures and persistence for different caching needs.