Caching Strategies

Keep frequently read data close and fast, and decide carefully how it stays fresh.

Intermediate10 min read3 interview questions

A cache stores the result of an expensive operation — a database query, an API call, a rendered page — so the next request can be served from memory in a fraction of the time.

Caching is the single most effective performance tool, and also a common source of bugs. The hard parts are invalidation (when is cached data wrong?) and isolation (whose data is this?).

Diagram

1. look up key2. on miss, query3. store resulthit: ~1 msApplicationCache (Redis)in-memory, TTLDatabasesource of truthResponse
Cache-aside: check the cache first, fall back to the database on a miss, then populate the cache.

Key concepts

Cache-aside (lazy loading)
The app reads the cache, and on a miss loads from the database and writes the cache. The most common pattern.
Write-through
Writes go to the cache and the database together, so the cache is always fresh. Slower writes.
Write-behind
Writes go to the cache and are flushed to the database later. Fast, but data can be lost on a crash.
TTL
Time to live — the cache entry expires automatically after a set period.
Eviction
When memory is full, entries are removed, typically least recently used (LRU) first.
Cache stampede
Many requests miss at once and all hit the database. Solved with locking, request coalescing or early refresh.

Trade-offs

Benefits

  • Huge latency reduction for repeated reads
  • Protects the database from read load
  • Absorbs traffic spikes

Costs

  • Stale data until invalidated or expired
  • Another system to run, size and monitor
  • Hidden bugs when keys miss a tenant or user ID

Use it when

  • Read-heavy data that changes rarely: catalogues, settings, profiles
  • Expensive computations or slow third-party calls
  • Session storage for stateless servers

Common mistakes

  • Cache keys without tenant or user scope — one customer sees another’s data
  • No TTL, so stale data lives forever
  • Caching errors or empty results without meaning to

Interview questions

Q1How do you keep a cache consistent with the database?
Usually by deleting the cache key when the data changes and letting the next read repopulate it, combined with a TTL as a safety net. Strong consistency needs write-through or no cache for that data.
Q2What is a cache stampede and how do you prevent it?
A popular key expires and thousands of requests hit the database at once. Prevent it with a lock so one request rebuilds the value, staggered TTLs, or refreshing before expiry.
Q3Where can caching happen in a web system?
Browser, CDN edge, reverse proxy, application memory, a distributed cache like Redis, and the database’s own buffer pool.