Caching Strategies

Caching is often the single highest-leverage technique for improving system performance — and one of the most commonly probed topics in interviews.

Where to Cache

Client-side (browser), CDN edge caching, a dedicated cache layer like Redis or Memcached in front of your database, and database-internal query caching are the main layers — each trades freshness for speed differently.

Cache Invalidation Strategies

Write-through updates the cache and database together, keeping them consistent but adding write latency. Write-back writes to cache first and flushes to the database later, faster but riskier. Cache-aside (lazy loading) only populates the cache on a read miss, which is the most common pattern in practice.

Cache-aside is popular specifically because it fails gracefully — if the cache is empty or gets flushed, requests simply fall through to the database and repopulate it, rather than the system breaking outright. That resilience is usually worth calling out explicitly when you propose it.

The Hard Part: Staleness

"There are only two hard things in computer science: cache invalidation and naming things." Set sensible TTLs, and be explicit in interviews about which data can tolerate staleness (a product listing) versus which can't (an account balance).

Cache Eviction Policies

Caches have finite memory, so something has to decide what gets removed when it's full. LRU (least recently used) is the most common default. LFU (least frequently used) suits workloads with a stable set of "hot" items. Naming the eviction policy shows you understand caches aren't infinite.

Where Caching Fits in an Interview Answer

Caching is rarely the whole design — it's the fix you reach for once you've identified a specific read-heavy bottleneck. Introduce it after you've shown the bottleneck exists, not as a default first move.

The Thundering Herd Problem

A subtle failure worth mentioning: if a popular cache entry expires and thousands of requests arrive simultaneously, they can all miss the cache at once and slam the database with identical queries. Techniques like request coalescing (letting one request populate the cache while others wait) or staggered TTLs prevent this — bringing it up unprompted signals real production experience.