Cache Read/Write Strategies

How data moves between an application, its cache and its database: cache-aside, read-through, write-through and write-behind, plus invalidation and stampede protection.

Overview

A cache keeps copies of data in fast memory so most reads skip the database. The hard part is not the cache itself but the rules for keeping the copy and the original in step: who fills the cache on a miss, what happens to the cache on a write, and how long an entry may live.

There are four standard patterns. Two are about reads: cache-aside, where the application fills the cache, and read-through, where the cache fills itself. Two are about writes: write-through, where every write updates the cache and the database together, and write-behind, where the cache takes the write and saves it to the database later. Real systems combine them, usually cache-aside for reads with a delete or an update of the cache on every write, and a TTL (time to live) on every entry as a safety net.

Each pattern trades something: freshness, write latency, the risk of losing writes, or how much of the cache is wasted on data nobody reads.

What you will be able to do

  • Describe the four patterns and who talks to the database in each.
  • Explain why deleting a cache entry on a write is safer than updating it, and where it still goes wrong.
  • Choose between write-through and write-behind, and say what write-behind can lose.
  • Stop a cache stampede with a lock or lease, request coalescing, or early refresh.
  • Pick a pattern and a TTL for each kind of data in a design.

Key concepts

  • Cache-aside (lazy loading)
  • Read-through
  • Write-through
  • Write-behind (write-back)
  • TTL
  • Invalidation by delete
  • Stale sets
  • Cache stampede
  • Request coalescing

Interview questions

  • Compare cache-aside and read-through. When would you choose each?
  • What are the trade-offs between write-through and write-behind caching?
  • How do you prevent a cache stampede on a popular key?
  • After a database write, should you update the cache or delete the entry? What can still go wrong?
  • Design the caching for a store with product pages, carts, stock counts and view counters.
  • Several services cache the same data. How do you keep their caches consistent?
  • How do you warm a cache, and when does it matter?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio