Write Path Patterns: Write Through, Write Behind, and Cache Aside with Delete on Write

Write Through
Write through updates both cache and origin synchronously: writes block until both succeed. Provides strong consistency (reads immediately see writes) at the cost of higher write latency. Database 5ms plus cache 1ms equals 6ms total unless parallelized. Use when read your writes consistency is critical: user facing counters (likes, votes), inventory systems, session data.
Write Behind
Write behind updates cache immediately and queues origin writes asynchronously. Offers low write latency (<0.5ms) but risks data loss on crashes and creates consistency windows where cache and origin diverge. Rare at scale without strict durability mechanisms. Appears in specialized scenarios: write heavy logging where losing a few entries is acceptable for throughput gains, or with write ahead logs and periodic checkpoints.
Cache Aside with Delete on Write
The dominant pattern: commit to origin first (ensuring durability), then delete affected cache keys, leaving reads to repopulate lazily. Separates write and cache concerns for fault tolerance. Critical ordering: commit before invalidate. Reversing allows stale data to be cached indefinitely when next read fetches old origin data. Race condition exists: if read happens between commit and invalidation, it might repopulate stale data. Mitigate with lease tokens: cache issues short lived tokens on misses, rejects sets if invalidation occurred since the lease was issued.
Choosing the Right Pattern
Default to cache aside with TTL safety net for 95% of use cases. Reserve write through for specific correctness requirements where write latency budget allows synchronous cache updates. Cache aside adds 0.5-2ms for invalidation messages vs baseline.

💡 Key Takeaways

✓Write through: synchronous cache + origin update. Strong consistency, doubled write latency (5ms + 1ms = 6ms). Use for counters, inventory, sessions.

✓Write behind: async origin write after cache update. Low latency but data loss risk on crash. Rare at scale without durability mechanisms.

✓Cache aside with delete on write: commit to origin first, then invalidate cache. Dominant pattern, separates concerns for fault tolerance.

✓Commit before invalidate is critical: reversing allows stale data to be cached indefinitely.

📌 Interview Tips

1Explain write through latency: database 5ms + cache 1ms = 6ms total. Worth it for counters, inventory where consistency is critical.

2Cache aside race condition: read between commit and invalidation repopulates stale data. Lease tokens mitigate: reject sets after invalidation.

3Default recommendation: cache aside with TTL safety net for 95% of cases. Write through only when consistency justifies extra latency.

← Back to Cache Invalidation Strategies Overview