Write-back (write-behind) cache

Problem

Write throughput is high; every write hitting the DB creates load. But you don't need writes to be durable in the DB immediately.

Context

Analytics counters, session updates, telemetry — writes that can be batched and flushed asynchronously.

Solution

Writes go to the cache and return immediately. A background flusher batches cache writes and periodically writes them to the DB (or drops them if they're aggregatable — e.g., counter increments).

Trade-offs

• Writes may be lost if cache dies before flush
• Read-your-write consistency: if the reader reads from DB, they see stale data (should read from cache)
• Flush lag makes debugging harder — 'why is this value in cache but not in DB?'

Failure modes

• Cache OOM: pending writes accumulate faster than flush
• Cache node death loses pending writes — must replicate the cache for durability
• Flush job crash silently drops writes

When to use

• High-write, loss-tolerant workloads (analytics, activity counters)
• Aggregatable writes (increment counter by 1 many times → flush as single write)

When NOT to use

• Any write that must be durable (money, orders, user account changes)
• Reads that must see the latest write