Caching strategies

A caching strategy is a wiring diagram for two paths

When you put a cache in front of a slower store, you have to answer two questions, and the answers are independent. On a read, who talks to the database when the cache misses — the application, or the cache itself? On a write, does the new value go to the cache, the database, or both, and in what order? The named strategies — cache-aside, read-through, write-through, write-back, write-around — are just the small set of sensible answers to those two questions. They are not features you toggle; they are the actual data flow, and choosing one fixes your freshness guarantee, your miss penalty, and your behaviour when the cache node dies.

The five strategies split cleanly: cache-aside and read-through are read-path patterns (how data gets into the cache), while write-through, write-back, and write-around are write-path patterns (what a write does to the cache). Real systems combine one of each — the most common production pairing is cache-aside reads with write-around or TTL-based writes.

By the end of this lesson you’ll know exactly what choice the team in the hook made by accident — and how to make it deliberately for your own data.

Cache-aside (lazy loading): the application orchestrates

In cache-aside — AWS calls it lazy loading — the application owns the logic. On a read: ask the cache; on a hit, return it; on a miss, query the database, write the result back into the cache, and return it. The cache is a dumb key-value box that knows nothing about your database.

READ (cache-aside):
  v = cache.get(key)
  if v is null:               # miss
      v = db.read(key)        #   trip to DB
      cache.set(key, v, ttl)  #   populate
  return v

Its virtues are exactly the ones AWS lists: only requested data is cached (the working set fills naturally, you never warm data nobody reads), and a node failure is survivable — a fresh empty cache node just produces misses that fill it back up, with degraded latency but no outage. Its costs: every miss is a three-trip penalty (cache miss, DB read, cache write), and because nothing updates the cache when the database changes, cached values go stale unless you add a TTL or invalidate on write. That staleness is precisely the bug in the hook.

Read-through: the cache orchestrates

Read-through moves the miss logic into the cache layer (or a library/provider in front of it). The application only ever calls cache.get(key); on a miss the cache itself loads from the database, stores the value, and returns it. The data flow is identical to cache-aside — the difference is who writes the code. Read-through centralizes the load logic so every caller behaves consistently and you can’t ship a service that forgets to populate on miss; the trade is that you need a cache provider that supports it and you lose the freedom to shape each query.

The three write strategies: where the write lands

When you touch a write path, you’re not just saving data — you’re deciding whether the cache stays honest, takes a performance shortcut, or gets bypassed entirely. That decision has a name. On the write path, the question is what write(key, value) does to the cache. Three answers:

• Write-through — write the cache and the database synchronously, on every write. The cache is never stale (it’s updated whenever the DB is), but every write pays two trips, and you fill the cache with data that may never be read (cache churn) — which is why write-through is usually paired with a TTL to evict the unread junk. AWS notes the freshness/latency trade exactly: writes get slower, but users tolerate write latency more than read latency.
• Write-back (write-behind) — write the cache now, return to the caller, and flush to the database asynchronously (batched, later). This gives the lowest write latency and absorbs write bursts by coalescing many updates into fewer DB writes. The danger is brutal: if the cache node dies before the flush, those acknowledged writes are gone. Write-back trades durability for speed, so it fits metrics, counters, and view-counts — not money.
• Write-around — write only the database and skip the cache; the value enters the cache later, lazily, on the next read (via cache-aside). This avoids churning the cache with write-heavy data that isn’t read soon, at the cost of a guaranteed miss on the first read after a write. It fits write-once-read-maybe data like logs.

Together, these three strategies mean you’re trading write latency, durability, and freshness against each other. When you see write-back in a design, the question to ask immediately is: what data can we actually afford to lose if this node goes down before the flush?

Consistency: what each strategy promises and breaks

The whole point of choosing is that each strategy makes a different freshness promise:

• Cache-aside / write-around / read-through all allow stale reads between a DB change and the cache’s next refresh — they need a TTL or explicit invalidation to bound the staleness. This is the common, accepted trade: a few seconds of staleness for huge read throughput.
• Write-through is the only one that keeps the cache continuously consistent with the DB on writes — but it does not protect you against an update that bypasses the cache (a batch job, a second service writing the DB directly), which silently reintroduces staleness.
• Write-back is inconsistent with the DB by design during the flush window, and risks data loss on cache failure — the strongest performance, the weakest durability.

The senior framing: there is no “fresh and fast and durable” option; you are choosing which of the three to sacrifice, per data class. Prices and balances want write-through or explicit invalidation; a trending-items list is fine cache-aside with a short TTL; a view-counter is a textbook write-back.