Write-Back (Write-Behind) Caching

Write-Back Caching (also known as Write-Behind) is an asynchronous caching pattern designed for ultra-high write throughput.

The Write-Back Execution Flow:

1. When a client performs a write operation (e.g., updating a score, incrementing a video view counter, or recording an IoT sensor metric), the application writes exclusively to the in-memory cache.
2. The cache immediately marks the memory entry as "Dirty" (modified in memory, unpersisted on disk) and returns an HTTP 200 OK success response to the client in sub-millisecond time (< 0.5ms).
3. An asynchronous background worker daemon periodically drains the dirty key queue (e.g., every 5 seconds or when a buffer reaches 1,000 items) and flushes the modified records to the persistent database as a batched bulk write.

The core superpower of Write-Back caching is Write Coalescing (Write Merging):

Suppose a viral video on YouTube or TikTok receives 10,000 views per second:

• Without Write-Back (Direct DB Writes): The database must execute 10,000 individual SQL UPDATE videos SET views = views + 1 statements per second, generating thousands of random disk I/O operations and saturating database row lock queues.
• With Write-Back Caching: Redis increments an in-memory integer: INCR video:42:views (10,000 ops/sec in RAM with zero disk I/O). Every 5 seconds, the background flusher reads the aggregated delta (+50,000) and executes a single SQL update:

  sql
  Copy
  UPDATE videos SET views = views + 50000 WHERE id = 42;

• Result: Reduces database write operations by 99.98\%, saving massive disk IOPS and server costs.

The trade-off for extreme speed is the risk of permanent data loss:

If the cache server experiences a hardware crash, kernel panic, or sudden power outage after acknowledging writes to clients but before the 5-second background flush completes:

• All uncommitted dirty memory state is permanently lost.
• For a video view counter or gaming leaderboard, losing 3 seconds of increments during an outage is completely acceptable.
• For a bank transfer, credit card checkout, or medical ledger, losing 3 seconds of writes is a catastrophic compliance violation.

Architectural Durability Mitigations:

1. Redis AOF (Append-Only File) Persistence: Set appendfsync everysec so mutations are flushed to disk logs every second.
2. Synchronous In-Memory Replication: Replicate memory writes to a hot standby replica across availability zones before returning success to the client.
3. Write-Ahead Logging to Kafka: Pipe mutations into an append-only Kafka topic before acknowledging memory writes.