Stop 23 · Interview PreparationTechnical · 5/8

Caching strategies

In short

"How would you make this faster?" usually leads to caching. The follow-up is where interviews are won: when does the cache go stale, and what happens when it does?

Being able to discuss where and how you'd add caching to a system, and the trade-offs of different invalidation strategies — a very common follow-up in system design interviews.

The purple blob cooks and takes a pinch from a spice box next to the pan.

Think of it like this

The masala dabba next to the stove

Haldi, jeera and mirchi sit in a small box right by the stove, because you use them every day. The big jars stay in the storeroom. Refill the dabba when it runs low, and don't forget it when you switch brands.

Watch it happen

Cache-aside: read, then update

API

Redis

Postgres

GET product:42

1/6First, check the cache.

The big ideas

What you need to know

Cache-aside

The app checks the cache, falls back to the database and fills the cache. The most common pattern.

Write-through and write-behind

Write-through updates cache and database together. Write-behind writes the cache first and the database later, faster but riskier.

TTL and invalidation

Every key should expire. On updates, delete or refresh the key. Decide how stale is acceptable.

Stampedes

When a hot key expires, thousands of requests may hit the database at once. Use locks, early refresh or jittered TTLs.

See it in code

Walk through the code

1async function getProduct(id: string) {2  const key = `product:${id}`;3  const cached = await redis.get(key);4  if (cached) return JSON.parse(cached);                  // hit: no DB query5 6  const product = await db.product.findUnique({ where: { id } });7  if (product) await redis.set(key, JSON.stringify(product), "EX", 300); // 5 min TTL8  return product;9}10 11async function updatePrice(id: string, pricePaise: number) {12  await db.product.update({ where: { id }, data: { pricePaise } });13  await redis.del(`product:${id}`);                        // invalidate after the write14}

1/3Try the cache first. A hit returns immediately.

Deleting after the write is simpler and safer than writing the new value into the cache, which can race with a concurrent read.

Save yourself the pain

Common mistakes

Oops

Caching without a TTL and hoping invalidation always works.

Do this instead

Always set a TTL as a safety net, even if you also delete keys on updates.

Oops

Caching per-user data under a shared key like "dashboard".

Do this instead

Include the user or tenant in the key, like dashboard:user:7, or users see each other's data.

Your mission

Measure a cache

~35 min

Quick check

With cache-aside, what should the API do after updating a product's price in the database?

Go deeper

1Prepare a real example from your own projects where caching mattered.
2Be ready to explain cache-aside, write-through and TTL-based invalidation from memory.
3Practice reasoning about what NOT to cache — highly personalized or frequently changing data.

More technical at this stop