Topic 10.5
Write-back (Write-behind)
In one line
Writes land in the cache and flush to the store asynchronously — fast writes, batched persistence, riskier.
Think of it like this
Quickly scribbling a to-do on a sticky note (cache) and copying it into your proper diary (database) later that evening, instead of writing it in the diary immediately. Faster now, but if you lose the sticky note before copying it, that to-do is gone.
Key ideas
- 01
Write path: update cache (fast), mark dirty, a flush job writes the store on a cadence/batch.
- 02
Win: write latency ~cache speed; store writes batched (fewer IOPS, aggregated).
- 03
Risk: a cache crash before flush LOSES acknowledged writes — durability gap.
- 04
Fix patterns: WAL/replication of the cache, or accept & scope it to non-critical data (counters, sessions).
- 05
Good fit: counters/increments, telemetry, anything where 'at most a few seconds stale' is fine.
- 06
Interview: 'write-behind with a replay log and idempotent flushes' is the advanced sentence.
Java / Spring map
- →
Spring: write to Redis + a @Scheduled flush to the DB; or queues to decouple (async).
Code & diagrams
Explain without notes
The product accepted a '5-second durability gap'. Which data would you NEVER allow this for?
Practice
Design a visit-counter: Redis INCR + batched flush to the DB, with the failure story stated.
Trade-offs
- ↔
Latency + batching vs acknowledged-write durability. The classic 'tune the durability dial' casе.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can scope write-behind to data whose loss window is acceptable — and say the window.