Answer first, save later
Write-behind tells the client the write worked as soon as your cache has it, and flushes to your database later, after a delay or in batches.
Watch your write path become a memory operation measured in fractions of a millisecond, while your database sees smoothed batched traffic instead of every individual write.
Take the lever this gives you on write-heavy work. A counter incremented ten thousand times a second can flush once a second as a single update.
The bad news
Now hear the bad news, which is genuinely bad. Between your acknowledgement and your flush, the only copy of that write lives in cache memory.
Lose the cache node in that window and the data is gone, and you already told somebody it was saved. Replicating the cache narrows the window without closing it.
Restrict it to data you can afford to lose a few seconds of. View counters, like counts, telemetry, presence, leaderboard scores.
Push back when somebody proposes it for orders or balances. The right question is what the apology email says after the first crash.
Notice the second, sneakier problem: your database is no longer current. Anything reading it directly, an analytics job, a downstream service, a support dashboard, sees data lagging by your flush interval.
Understand what you just did organisationally. Write-behind quietly promotes your cache to the source of truth for recent data, and everybody else in the company has to know that.
Watch your flush queue depth operationally. If your database slows and flushes fall behind, unflushed writes pile up and your loss window grows from seconds to minutes with nobody changing a line of code.
Cap that queue, alert on its depth, and decide in advance whether overflowing blocks new writes or drops old ones.
Worked example
Marcus works on a video platform where every play, pause, and seek fires an event that updates per-video engagement counters. Writing each of the 80,000 events per second straight to Postgres was never going to work; the primary fell over at 15,000. The team moved counters to Redis with write-behind: INCR in memory on every event, and a worker flushes aggregated deltas to Postgres every 2 seconds as a few hundred batched UPDATEs. Postgres write load dropped by roughly 99 percent. The known cost showed up eight months later when a Redis node was OOM-killed and about 1.5 seconds of counter increments vanished, roughly 120,000 events. The on-call runbook already covered it: view counts are approximate by contract, nobody reconciles, and the incident closed in twenty minutes with no customer impact.