Cache-Aside vs Write-Through: Who Owns Cache Population
The ownership question nobody asks until the cache and the database drift apart: which component holds the fill and write logic?
Core Concept
Cache population is not a single policy — it is two separate paths, and each path can be owned by a different actor.
Cache-Aside (lazy loading): the application owns the read path. On a miss, the app fetches from the database, writes the entry into the cache itself, then returns it. The cache stays a passive key-value store that knows nothing about the database.
Write-Through: the cache owns the write path. The app writes to the cache, and the cache synchronously persists to the backing store before it acknowledges — one logical update.
Key Components
Cache-Aside
App fetches from the DB on a miss and fills the cache itself. Resilient: a cache outage degrades to slow-but-correct. Only caches what is actually requested.
Write-Through
Cache persists to the DB synchronously before acknowledging. Keeps the cache warm and consistent on writes, centralises the logic, but pays DB latency on every write.
Read-Through
The true read-path counterpart of write-through: the cache itself fetches from the DB on a miss, and the application never sees the fill at all.
Write-Behind
Write-back: acknowledge first, persist asynchronously. Faster, but can lose acknowledged writes if the cache dies before the flush lands.
The Axis Correction
They are not opposites. Framing cache-aside vs write-through as a single dichotomy invites a false either/or.
Cache-Aside / Read-Through — who fetches and fills on a miss?
Write-Through / Write-Behind — who persists to the store?
These describe different axes. Production systems routinely run cache-aside reads together with write-through writes — the app owns the fill, the cache owns the persist.
How It Works
- Read miss, cache-aside: app checks the cache → miss → app queries the DB → app writes the row into the cache → returns it. The cache never touched the database.
- Write, write-through: app writes to the cache → cache blocks until it has written the same value to the DB → only then acknowledges the app.
- The guarantee boundary: “synchronously” means the cache waits for the store — it does not mean the pair is atomic. There is no distributed transaction: the DB write can succeed while the cache ack is lost, or the process can die between the two. It reduces divergence without eliminating it.
How to Falsify It
- Kill the cache mid-traffic. The cache-aside read path still serves correct data — just slowly. A write-through write path fails outright. Same store, different failure.
- Fire N concurrent requests for one cold key. Count DB queries: cache-aside issues many without single-flight, exposing the stampede that write-through does not have.
- Write a key, then read it before any TTL expiry. Compare with and without write-through to see the warm-cache difference on the write path.
- Run the real combination. Stand up an endpoint with cache-aside reads and write-through writes — proof that the two policies are orthogonal, not a fork in the road.
Checkpoint — answer before you move on
In cache-aside, who writes the entry into the cache on a read miss — and what does that make the cache itself?
Think: does the cache know the database exists?
Why are cache-aside and write-through not opposites? Name the true read-path counterpart of write-through.
One is a read-path policy, the other a write-path policy.
In write-through, “synchronously” means the cache waits for the store. Does that make the cache + database pair atomic? What can still go wrong?
There is no distributed transaction.