A database lookup costs 1–10ms. A cache lookup costs 0.1–1ms. Your feed page makes 40 lookups. Without a cache you're over 100ms just on DB; with one you're under 5ms. That's the difference between a snappy app and a slow one.
But "put a cache in front of the DB" hides a design choice with five different answers, each wrong for some workload. The right cache strategy for a product catalog is the wrong one for a payment ledger.
Think of a barista's memory. A customer orders a latte. Does the barista (a) always look up the recipe in the manual and write results on a sticky note after (cache-aside), (b) write to the manual AND their sticky note at the same time (write-through), (c) only update the sticky note and sync to the manual later (write-back), or (d) skip the sticky note entirely for writes (write-around)?
Each choice trades consistency for latency in a different direction. None is universally best.
| Strategy | Read path | Write path | Best for |
|---|---|---|---|
| Cache-aside | Check cache → miss → read DB → fill cache → return | Write DB, delete or update cache | Most app caches — read-heavy, tolerates brief staleness |
| Write-through | Check cache → miss → read DB → fill cache | Write cache AND DB synchronously. Both succeed or fail. | When reads immediately after writes must be fresh |
| Write-back | Same as write-through | Write cache, acknowledge. Async flush to DB later. | Write-heavy, tolerates data loss on crash (counters, analytics) |
| Write-around | Same as cache-aside | Write DB only. Cache filled on next read. | Write-once-read-rarely data (logs, audit trail) |
| Refresh-ahead | Cache hit returns stale if expiring soon; background refresh triggered. | Writes go to DB as normal | Predictable hot keys you want to pre-warm (feed caches, homepage) |
Cache can crash and reads still work (they just hit the DB). Writes don't block on cache. Problem: a read and a write racing can leave stale data in the cache. Mitigate with DELETE-on-write rather than UPDATE-on-write.
Every successful write is readable from cache immediately. Problem: every write is now two operations. Cache outage blocks writes. Use only when you genuinely need read-after-write consistency (user profile updates, settings).
"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton. The harder the consistency you promise, the more expensive invalidation becomes. Prefer short TTLs with cache-aside over "perfect" invalidation logic.
Consider two clients hitting the same key:
v1)v2)v1Cache now holds v1; DB holds v2. Cache is stale forever (until TTL). This race exists in any cache-aside system. Mitigations:
{value, version}. On write, A's version is older, gets rejected.The interview answer: "cache-aside is correct for most workloads if you pair it with short TTLs. If you need read-after-write, switch that specific key's strategy to write-through — don't redesign the whole cache."
Billions of entries, 99% read hit rate. Uses leases to mitigate the stale-read race — a reader holds a lease while filling, subsequent writers wait.
The textbook setup. App checks Redis, falls back to Postgres, stores result. Delete on write. TTL of 60s–24h depending on volatility.
AWS's managed cache in front of DynamoDB. Writes go through DAX, which writes to DynamoDB synchronously. Zero stale reads.
CDNs rarely see writes — they pull from origin on first request (write-around is implicit). Invalidation is explicit (POST /purge).
URL shortener caches redirects (cache-aside, TTL 24h). News feed caches rendered feeds (cache-aside + refresh-ahead). Ticketmaster caches event availability (write-through to keep inventory accurate).
