Write-behind

Write-behind (write-back) acknowledges writes to cache immediately and asynchronously flushes to the database in batches. It reduces write latency and smooths spikes but risks data loss if cache fails before flush unless durability is engineered with WAL or replication.

Requires ordering guarantees, replay after crash, and backpressure when the database cannot keep pace. Good for analytics counters or session writes with loss tolerance — dangerous for financial records without careful design.

On interviews: explain when write-behind fits a view-counter use case, loss window on crash, and durability mitigations.

Common pitfalls: unbounded write buffer growth; flush lag causing large recovery replay; using write-behind for money movement.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Define acceptable loss window.
• Persist WAL before ack if durability needed.
• Batch and rate-limit flush to database.
• Monitor flush lag and buffer depth.