What caching patterns do you use in front of a database, and how do you keep the cache consistent?

Question

Accepted Answer

The pattern I reach for most is cache aside, or lazy loading. The application checks the cache first, and on a miss it reads the database, writes the result back into the cache, and returns it, so the cache fills only with data that is actually requested. The alternatives are write through, where every write goes to the cache and the database synchronously, which keeps them consistent but adds maybe 2 to 5 milliseconds to each write, and write behind, where you write to the cache and flush to the database asynchronously, which is fast but risks losing data if the cache dies before the flush. The real engineering problem is not the read pattern though, it is invalidation and consistency. When data changes the cached copy is wrong, so on a write I either delete the cached entry so the next read repopulates it, or update it in place. And I always set a TTL as a safety net, so any entry I forget to invalidate still self heals inside a bounded window. The honest framing is that caching trades consistency for performance, there is always a staleness window, so I choose the TTL per data type by how much staleness the business can tolerate. An account balance gets near zero, a few seconds at most or no caching at all. A product catalogue can happily sit at a 10 minute TTL. So, cache aside by default, write through when I need stronger consistency, and a deliberate invalidation plus TTL strategy, because that is the part that actually bites.

Answer

Why is cache invalidation considered one of the hard problems?

On every write you must reliably update or evict the right cached entries, across multiple keys and nodes, or readers get stale data. Missed invalidations cause subtle, hard-to-reproduce staleness bugs; TTLs bound the damage but do not eliminate it.

Answer

When would you choose write-through over cache-aside?

When you need the cache and DB to stay tightly consistent and can accept slower writes, the cache is updated on every write so reads never miss freshly written data, avoiding the cache-aside staleness window.

What caching patterns do you use in front of a database, and how do you keep the cache consistent?

What caching patterns do you use in front of a database, and how do you keep the cache consistent?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with databases

Knowing the answer is not the same as recalling it under pressure