Cache-aside vs Write-through Interview Questions

Cache-aside is what I use most. The app reads Redis. On miss it reads the DB, then fills Redis. On write it updates the DB and then deletes or updates the cache key. It is simple and the cache only holds what people actually read. The risk is a stale key if I forget to invalidate. Write-through: the app writes to the cache, and the cache writes to the DB before success. Consistency is better, writes are slower. Write-behind writes the cache first and flushes the DB later. Fast, but I can lose writes if Redis dies. For a normal web API I would pick cache-aside plus a TTL, and I would say the invalidation path out loud so they know I thought about staleness.

Read: GET, miss, DB, SET. Write: DB then delete or update the key. I prefer delete so the next read fills. TTL is a safety net if invalidation misses.

Cache first, DB async. Fast, can lose data if Redis dies. I would not use it for payments. Analytics counters maybe. Durability class first.

Invalidation event or delete from the writer. Two writers without a rule will stale. Namespace by version. TTL of one hour does not save a price page. Cross-service cache is a design problem.

If the data is per user, yes, or I leak another cart. Global config, no. Do not put PII in keys that hit logs. Key design is half of caching.