Caching Strategies
Storing a fast copy of expensive-to-compute or expensive-to-fetch data — write policies, eviction, and the invalidation problem.
Try answering in your head first, then click a question to check the model answer.
Q1.Explain the cache-aside pattern and one downside of it.(show answer)
The application checks the cache first; on a miss, it reads from the database, then populates the cache for future requests. Downside: the first request after a miss (or cache expiry) always pays the full database latency, and there's a window where the cache and database can briefly disagree if the underlying data changes without an explicit invalidation.
Q2.Why is cache invalidation often called one of the hardest problems in computer science?(show answer)
It requires correctly identifying every place a piece of cached data could become stale — and either updating or evicting it — without over-invalidating (defeating the point of caching) or under-invalidating (serving incorrect stale data). This gets harder as data relationships get more complex, since a single underlying change can invalidate many derived cached values in non-obvious ways.
Q3.How does a cache stampede happen, and what's one way to mitigate it?(show answer)
When a popular cached key expires (or is evicted), many concurrent requests can miss the cache simultaneously and all hit the database at once, potentially overwhelming it. Mitigations include: locking so only one request repopulates the cache while others wait briefly, or probabilistic early expiration/refresh (refreshing slightly before actual expiry, staggered across requests) so not every request expires at exactly the same instant.
Q4.When would write-through caching be preferred over cache-aside?(show answer)
Write-through writes to the cache and the database together on every write, keeping them always in sync — preferred when read-after-write consistency matters (a user should immediately see their own write reflected) and the extra write latency (writing to both cache and DB synchronously) is acceptable. Cache-aside is simpler and doesn't pay that write-path cost, but tolerates the cache being briefly stale or missing until the next read repopulates it.