Write-Behind Cache

Acknowledge writes to cache immediately and flush to the database asynchronously, so write latency seen by the caller is cache write latency rather than database write latency.

Write latency to the database is too high for the application's response time requirement, and the written data does not need strict durability guarantees on every write.

Also called write-back caching. The application writes to the cache, receives an immediate acknowledgment, and returns to the caller. A background process (flush worker, cache eviction handler, or TTL-triggered flush) later drains the cache writes to the underlying database.

Contrast with the two other write strategies: - Write-through: writes go to cache and database synchronously before

acknowledging. Latency = database write latency. Consistent but slow.

- Cache-aside: application manages cache explicitly; reads and writes both

go to database directly, with cache populated on cache miss. Simplest model.

- Write-behind: writes go to cache only, acknowledged immediately, flushed

asynchronously. Fastest write latency; highest durability risk.

Risk profile: data written to cache but not yet flushed to the database is in-flight. If the cache process crashes, reboots, or is evicted before the flush, that data is permanently lost. This is acceptable for: - Metrics and counters (approximate totals survive; exact counts do not) - Session data (loss means re-authentication) - User activity tracking (best-effort analytics) - Real-time leaderboards (minor score corrections are tolerable)

It is NOT acceptable for: - Financial transactions (charge, payment, transfer) - Order state transitions - Any operation that must be durable and auditable - Systems with regulatory durability requirements

Implementation variants: 1. Queue-backed flush: cache write also appends to a durable write queue

(Redis Streams, SQS). A worker drains the queue to the database. The

queue provides durability that the cache alone does not: unflushed writes

survive a cache restart as long as the queue is durable.

2. TTL-flush: cache key is set with a TTL; on expiry or eviction, a callback

writes the value to the database. Simpler but less reliable: cache eviction

under memory pressure can trigger premature or missed flushes.

Redis persistence options (RDB/AOF) reduce but do not eliminate durability risk for unflushed writes, because AOF fsync intervals introduce a window of data loss on crash.