Write-Through Cache
Every write updates the cache and the database together.
StarterData
Writes go to the cache, which synchronously writes through to the database. Reads always hit a cache that is never stale, at the cost of every write paying both latencies.
When to use it
- Reads must never see stale data and can tolerate slightly slower writes
- Write volume is low enough that the extra hop does not become the bottleneck
Trade-offs
- Every write pays cache and database latency, unlike cache-aside
- Cache becomes a write dependency, not just an optional accelerator
Components used
Managed App ServiceCacheRelational Database
How it works
- Every write goes to the cache, which synchronously writes through to the database before acknowledging.
- Reads are therefore almost always hits, and the cache is never stale relative to the database.
- The cost is write latency: every write now pays for two hops instead of one.
Used in the wild
- Workloads where data is read many times shortly after being written.
- Session and profile stores where stale reads are unacceptable but read volume is high.
- Paired with write-behind for the subset of writes that can tolerate async persistence.
Good to know
- It fills the cache with data that may never be read, wasting memory on write-heavy workloads with poor read locality — the inverse of cache-aside's problem.
- Unlike cache-aside, a cache outage here is an outage of the whole write path, since the cache sits inline rather than beside it.
Related patterns
Retrieval-Augmented Generation (RAG)
Ground an LLM's answers in retrieved, up-to-date, private documents.
Vector Search + Rerank
Cheaply retrieve a broad candidate set, then precisely re-rank the top results.
Feature Store
Compute features once, serve them consistently to training and inference.
CQRS
Separate models and stores for writes and reads.