Caching — SDE-1 Interview Questions#

Definition: A cache is a fast, temporary storage layer that holds copies of data so future requests can be served faster without hitting the original source.

The key idea — avoid repeating expensive work by storing the result closer to where it's needed. The expense could be a slow DB query, a network call to a third-party API, or an expensive computation.

Real-world analogy: Placing your daily reading book on your desk instead of walking to the bookshelf in another room every time. The book is the same — but the access time is drastically reduced. You don't move the bookshelf, you just keep a copy closer.

In production:

Third-party API response  → cache it → avoid calling API on every request
                             saves latency, avoids rate limits

DB query result           → cache it → 10,000 users reading same profile
                             don't trigger 10,000 DB queries

Computed feed             → cache it → don't re-rank 500 posts on every load

Cache Hit: Request comes in → data found in cache → returned immediately. DB never touched.

Cache Miss: Request comes in → data not in cache → fetch from DB → store result in cache → return to client.

Hit:  Request → Cache → Return ✓  (fast, ~1ms)

Miss: Request → Cache (empty) → DB → Store in Cache → Return
               next request  → Cache → Return ✓  (fast now)

The critical step candidates forget: store in cache after a miss. If you miss and don't store, every future request for the same data is also a miss — the cache never helps.

What TTL is: TTL (Time To Live) is a timer on a cache key. When the timer fires, the key is deleted automatically — regardless of whether the data has changed or not. It's purely time-based.

Why we set one: The cache doesn't automatically know when the DB changes. If a user updates their profile, the cache still has the old value. TTL ensures the key eventually expires so the next request fetches fresh data from DB.

It's a safety net — even if you forget to manually invalidate a key, it won't live forever.

What happens without TTL:

User updates profile at T=10s
No TTL set → cache key lives forever
→ cache serves old profile indefinitely
→ user sees their own stale data forever
→ memory fills up with keys never needed again

Choosing TTL values:

News feed like count   → stale 30s is fine    → TTL = 30s
User profile           → stale 5min is fine   → TTL = 300s
Bank balance           → stale 1s is not fine → don't cache, or TTL = 1s

The difference:

They are completely independent. Both can apply to the same key — whichever fires first wins.

Example where eviction fires before TTL:

Key "user:123:profile" set with TTL = 5 minutes

At T=3min → cache fills up with other hot data
→ LRU eviction fires → "user:123:profile" hasn't been accessed recently
→ evicted at T=3min, 2 minutes before TTL would have fired

Most common eviction policy — LRU (Least Recently Used): The key you haven't accessed the longest gets evicted first. Redis uses LRU by default. The intuition: if you haven't needed it recently, you probably won't need it soon.

The most important question first — should we even cache?

Before picking tools or strategies, validate that caching is actually the right solution:

Is this a caching problem at all?
  → Maybe the DB query just needs an index
  → Cache on top of a broken query just hides the problem

Is the data read frequently?
  → If read once and never again, caching wastes memory

Is staleness acceptable?
  → Stock prices, live inventory → don't cache
  → User profiles, feed content → fine to cache

Is the fetch actually expensive?
  → If DB query takes 1ms, caching adds complexity for no real gain

If yes to all — then ask implementation questions:

Which layer?        CDN, Redis, local in-process?
What data structure? String vs Hash vs Sorted Set?
What TTL?           Per data type?
What eviction?      LRU, LFU, TTL-only?
What write strategy? Cache-aside, write-through, write-back?