Write-through
A caching pattern where every write goes to the cache and the DB together, so the cache is always consistent with the DB. Reads then always hit. The tradeoff is write latency (two writes) and failure handling.
- Read-heavy with writes that must be immediately visible.
- When you want reads to never miss for written keys.
- Write-heavy workloads (latency doubles).
- When eventual consistency is acceptable and cache-aside is cheaper.
Definition
On a write, update the cache and the DB in the same operation (cache first or DB first). Reads can assume the cache is current. Stronger consistency than cache-aside at the cost of write latency.
Why it exists
Cache-aside invalidation can leave stale data or race. Write-through keeps the cache fresh on every write, so reads are fast and consistent without invalidation logic.
How it works
Write → SET cache + UPDATE DB. Order matters: write-through-cache-first is fast but risks data loss if the DB write fails; DB-first is safe but the cache may briefly be stale. Often paired with read-through for a fully cache-fronted store.
Scaling limits
Write latency includes both writes. If the cache write fails you must handle it (retry, log). Doesn't reduce write load on the DB — every write still hits it.
Cost shape
Two writes per mutation + cache memory. Blow-ups: write-heavy workloads paying double latency and cache churn.
Alternatives
- Write-behind — Async DB writes for fast writes, but risk of data loss.
- Cache-aside — Invalidation-based; cheaper writes, possible staleness.
Failure modes
- Cache/DB divergence if one write fails.
- Latency from synchronous double writes.