Write-Through

The Pattern

 ALL writes flow through the cache, which mirrors to storage
 SYNCHRONOUSLY:

 WRITE:
   app ──set──► [ cache ] ──sync write──► [ db ]
   returns only after BOTH acknowledge

 READ:
   always a hit (data was written through) → fast, consistent

 [app] ──write──► [cache] ══════► [db]     both updated atomically-ish
        ◄─ ack ───┘

What It Buys

 ✓ reads NEVER miss for written data → uniform low read latency
 ✓ cache and storage never diverge (synchronous mirror)
 ✓ no invalidation logic — write path IS the consistency mechanism
 ✓ reads-after-writes see fresh data immediately
 
 the pattern converts consistency work on reads into
 latency cost on writes. good trade when reads dominate
 and write rate is modest.

The Costs

Cost	Detail
Write latency	Two hops before ack; tail = max(cache, db)
Write amplification	Cold data gets cached even if never read
Cache churn	Write-once-read-never entities evict hot data
Coupled failure	Db slow → writes queue in/through cache

The churn row is the sneaky one: write-through everything and your cache fills with entities nobody will ever read, evicting the ones everyone does.

The Hybrid That Usually Wins

 write-THROUGH the hot subset, write-ASIDE the rest:

 - entities known hot (sessions, active carts): write-through
 - long-tail entities: plain db writes + cache.delete (cache-aside)
 
 or flip it: WRITE-BEHIND (next lesson) when write latency
 matters more than read perfection.
 
 patterns are tools per entity class, not religion.

Failure Semantics

 what if cache acks but db write fails?
 - MUST NOT report success to caller
 - roll back / mark failed; cache entry invalidated or corrected
 - exactly-once between two stores is its own hard problem;
   keep transactions as tight as possible, order: db first,
   then cache, on failure invalidate cache

 what if db succeeds but cache write fails?
 - next read misses → lazy fill from db → self-heals ✓
 - this direction is SAFE; design failure paths asymmetrically

When Write-Through Fits

 ✓ read-mostly data where stale reads are unacceptable
   (config, permissions, inventory thresholds)
 ✓ moderate write rates (hundreds–thousands/sec per key class)
 ✓ systems already treating cache as authoritative facade
 
 poor fit:
 ✗ heavy write streams (log ingestion → use queues instead)
 ✗ cold-heavy datasets (churn problem)
 ✗ cross-region (synchronous mirroring across regions hurts)

Interview Framing

Name it alongside its trade in one sentence: “write-through keeps reads uniformly fast by paying double-hop write latency.” Then volunteer the churn caveat and the hybrid. Candidates who present one caching pattern as THE answer get exposed by the follow-up “and your write path?”; having all four patterns sorted per-entity-class is the senior position.