BeginnerIn-depth3 min readUpdated 30 Sept 2026

What is caching and what caching strategies should you know?

SHORT ANSWER

A cache keeps a copy of frequently used data in faster storage, like memory, so repeated reads are quick. Know cache-aside, write-through and write-back, eviction policies like LRU, TTLs, and the hard part, keeping the cache consistent with the database.

Explain it simply

Imagine the college library is a 10-minute walk away. You keep the three books you use daily on your desk. Your desk is the cache: small but instant. When you need a new book, you walk to the library once and keep it on the desk. When the desk is full, you return the book you have not touched for the longest time. That last rule is called LRU, least recently used.

Example

Cache-aside, the most common pattern, in plain steps:

text

read(userId):
  value = cache.get("user:" + userId)
  if value exists: return value            // cache hit
  value = db.query(userId)                 // cache miss
  cache.set("user:" + userId, value, ttl = 10 minutes)
  return value

update(userId, data):
  db.update(userId, data)
  cache.delete("user:" + userId)            // next read reloads fresh data

How it works

Where caches live: in the browser (HTTP cache), at a CDN edge, in the app's memory, in a shared store like Redis, and inside the database itself.

Write strategies:

Cache-aside (lazy loading): the app reads from cache and fills it on a miss. Simple, and only needed data gets cached.
Write-through: every write goes to the cache and the database together. Reads are always fresh, writes are slower.
Write-back (write-behind): write to the cache now and to the database later in batches. Very fast, but data can be lost if the cache crashes.

Eviction: LRU (remove the least recently used), LFU (least frequently used) and FIFO. TTL (time to live) expires entries automatically so stale data does not live forever.

Measuring: hit ratio = hits divided by total reads. A 95% hit ratio means only 5% of reads reach the database.

Real-world use

Instagram-style feeds, product pages on Flipkart during a sale and cricket score pages all rely on caches because millions of people read the same thing. Even this site caches static files (CSS, JS, fonts) in your browser for a long time and uses file names that change when the file changes.

Common mistakes

Caching data that changes every second, which gives a low hit ratio and stale results.
Updating the cache and then the database, so a failed database write leaves wrong data cached.
No TTL at all.
Ignoring a cache stampede: a popular key expires and thousands of requests hit the database at once.

What to say in the interview

"Caching stores hot data in faster storage to cut latency and database load. I'd usually start with cache-aside in Redis: read from cache, on a miss load from the database and set it with a TTL, and on update write to the database then delete the key. I'd choose LRU eviction and watch the hit ratio. The main risks are stale data and stampedes, which I'd handle with sensible TTLs, deleting keys on writes and request coalescing or locks for hot keys."

Follow-up questions

How do you prevent a cache stampede?
Why delete the key on update instead of updating it?
What is the difference between Redis and Memcached?
How does a CDN decide what to cache?

Go deeper

Read these once the basics above feel easy.

Add jitter to TTLs so many keys do not expire together. Use a lock or "single flight" so only one request rebuilds a missing key. Negative caching stores "not found" results briefly so repeated lookups for missing data do not hammer the database.

#system-design #caching #redis #performance