In modern web applications, the database is almost always the primary bottleneck for scalability. Reading from physical disk (or even SSDs) requires milliseconds, whereas in-memory caches like Redis and Memcached deliver sub-millisecond responses.
However, introducing a cache creates distributed consistency challenges. This guide covers caching design patterns, cache invalidation strategies, and failure mitigations.
1. Caching Patterns: Cache-Aside vs Write-Through vs Write-Back
Cache-Aside (Lazy Loading): The application first queries the cache. On a cache hit, data is returned immediately. On a cache miss, the application queries the database, writes the result to the cache with a TTL, and returns it. This is the most popular caching pattern.
Write-Through: The application writes data to the cache, and the cache synchronously updates the primary database before confirming the write. Guarantees consistency at the cost of write latency.
Write-Back (Write-Behind): The application writes to the cache immediately; the cache batches asynchronous updates to the database later. Maximizes write throughput but risks data loss if the cache crashes before flushing.
2. Common Production Caching Pitfalls & Solutions
Cache Stampede (Dog-piling): When a high-traffic cache key expires, thousands of concurrent requests simultaneously hit the database. Solution: Use mutex locking or probabilistic early expiration (XFetch algorithm).
Cache Penetration: Requests for non-existent keys bypass the cache and hit the database repeatedly. Solution: Cache NULL values with a short TTL or use a Bloom Filter at the API layer.
Cache Avalanche: Multiple cache keys expire at the exact same timestamp. Solution: Add random jitter to TTL durations (e.g., TTL = base + rand(0, 300) seconds).
3. Cache Eviction Policies: LRU vs LFU
When cache memory is exhausted, Redis applies eviction policies:
Least Recently Used (LRU): Discards items that have not been accessed for the longest duration.
Least Frequently Used (LFU): Discards items with the lowest access frequency counter.
Frequently Asked Questions
Why does Phil Karlton say 'There are only two hard things in Computer Science: cache invalidation and naming things'?
Cache invalidation is notoriously difficult because maintaining strict consistency between two separate data stores (the database of record and the volatile cache) across distributed networks requires careful TTL management and event-driven invalidation.
When should I choose Redis over Memcached?
Choose Redis when you need rich data structures (Hashes, Sets, Sorted Sets, Bitmaps), persistence (RDB/AOF), pub/sub messaging, geospatial queries, or Redis Cluster clustering. Memcached is suitable for simple multi-threaded key-value caching.
Written by Aditya Sharma
Technical contributor and subject matter specialist at PrimerPrep. Dedicated to breaking down complex systems into transparent, verified engineering principles.
Ready to test your knowledge?
Put these concepts into action with our independently reviewed practice questions and coding challenges.
Start practicing free