Caching strategies

Why it matters

Deciding to cache is easy. Deciding who writes to the cache, and when, is the design. The strategy you pick determines how stale reads can be, how slow writes become, and what happens when the cache node disappears. Interviewers ask about it because the wrong strategy on the wrong workload is a correctness bug, not a performance tweak.

The idea

There are two questions. On a read miss, who fetches from the database and fills the cache: the application or the cache itself? On a write, does the data go to the cache, the database, or both, and in what order?

Read strategies

Cache-aside (lazy loading). The application owns the logic. It checks the cache, and on a miss it reads the database and writes the result into the cache. The cache is a dumb key-value store; the application knows the data model. This is the default in most codebases and the model Redis and Memcached assume.

Read-through. The cache owns the logic. The application only ever talks to the cache; on a miss the cache fetches from the database itself. Cleaner call sites, but the cache needs a loader for every data type. Common in library caches such as Caffeine or Guava, and in some managed services.

Write strategies

Write-through. Every write goes to the cache and the database synchronously. The cache is never stale for data written through it. Writes pay for two round trips.

Write-behind (write-back). Writes go to the cache and are acknowledged immediately; the cache flushes them to the database asynchronously, often batched. Fast writes and fewer database operations, but a cache crash loses unflushed data. Suitable when losing a few seconds of writes is acceptable, such as view counters or presence.

Write-around. Writes skip the cache and go to the database; the cache fills on the next read. Avoids polluting the cache with data that is written once and rarely read, such as logs or bulk imports. The next read after a write is always a miss.

	Cache-aside	Write-through	Write-behind	Write-around
Who fills on miss	Application	Cache or app	Cache or app	Application
Write latency	One write (DB)	Two writes, synchronous	One write (cache), fast	One write (DB)
Staleness window	Until TTL or invalidation	None for written keys	None in cache; DB lags	First read after write misses
Data loss on cache failure	None	None	Unflushed writes lost	None
Fits	General read-heavy workloads	Read-after-write correctness	Write-heavy, loss-tolerant	Write-once, read-rarely data

Combining them

Real systems mix strategies. A common pairing is cache-aside for reads with write-through for the fields the same user will read back immediately, so a user never sees their own update disappear. Another is write-around plus cache-aside for analytics ingestion, so bulk writes never evict the hot working set.

Trade-offs

Cache-aside is simple but makes every miss a two-step dance, and two concurrent misses can both fill the cache. Write-through protects correctness but makes every write slower and caches data that may never be read. Write-behind is fast and dangerous in equal measure. Write-around keeps the cache clean at the cost of a guaranteed miss.

There is no best strategy. There is a best strategy for a read-to-write ratio, a tolerance for staleness and a tolerance for loss.

In an interview

State the read-to-write ratio first; it decides most of the answer. Then name the strategy and justify it with the two tolerances: "Cache-aside with a 60-second TTL for the feed, because reads outnumber writes 200 to 1 and a minute of staleness is fine; write-through for profile edits, because users expect to see their own change immediately."

Mention what happens on a cache restart. For write-behind, say out loud that unflushed writes are lost and why that is acceptable here.