A client sends a write to Redis and receives an OK reply. What has actually been guaranteed at that instant, and what would you have to add for "this write is safe" to hold end-to-end — through the Redis process, the operating system page cache, the storage device, and other nodes?

## What the OK reply actually promises When Redis returns `+OK`, one thing has certainly happened: the command was executed against the in-memory dataset on the node that answered, and the effect is immediately visible to every other client reading that node. Nothing else is implied. With AOF enabled, the command has additionally been appended to an in-memory buffer that will be handed to the kernel at the end of the event-loop iteration. Only the strictest fsync policy makes Redis force that buffer to stable storage *before* the reply leaves. The exact loss window that each `appendfsync` policy and each RDB save point produces is a separate subject, owned by the persistence-configuration material; the point here is that visibility and durability are different properties, and the reply confirms only the first. There is also a rung below Redis: the client. If the connection breaks after the server executed but before the reply arrived, the client cannot tell whether the write happened. "Safe end-to-end" therefore starts with idempotent writes or a retry key, not with disk settings. ## The failure-domain ladder Each rung survives a strictly larger class of failure, and each costs more. **1. Redis process memory.** Survives nothing. `kill -9`, a segfault, the Linux OOM killer, or a container restart takes it. This is where an ordinary acknowledged write lives. **2. The OS page cache.** Reached when Redis calls `write()` on the AOF. The kernel now owns those bytes, so the data survives the Redis process dying — the kernel flushes later on its own schedule. It does not survive the kernel dying: a power cut, a panic, a hypervisor loss, or a cloud instance being terminated destroys page cache and process memory alike. **3. The storage device.** Reached when `fsync()` returns. This is the rung people believe is absolute, and it is the one that lies most often. A consumer SSD, a desktop disk with write-back caching enabled, or a RAID controller without a battery/flash-backed cache can acknowledge an fsync while the data still sits in the device's own volatile DRAM; a power cut then loses writes the operating system believes are durable. Enterprise drives with power-loss protection, or controllers with BBU/FBWC, are what make an fsync mean what you think it means. Network-attached cloud volumes add their own semantics and, importantly, their own latency — an fsync there can cost milliseconds, which is why `appendfsync always` collapses throughput on such storage. **4. Another node.** The only rung that survives losing the machine outright: destroyed disk, terminated instance, rack fire, or an availability zone going dark. No local fsync setting reaches it. The practical skill is naming which failure class you are defending against and stopping at the rung that covers it — a session cache legitimately stops at rung 1. ## The failover hole Redis replication is asynchronous by design: the master applies the command, replies to the client, and *then* streams it to replicas. So if the master dies and Sentinel or Cluster promotes a replica, everything the master had acknowledged but not yet shipped is gone — even if it was fsynced locally, because the promoted replica never received it. Worse, when the old master comes back it becomes a replica of the new one and resynchronises, discarding its own divergent tail. This is why "we set `appendfsync always`" is not an answer to "can we lose an acknowledged write": with automatic failover, the answer stays yes. `min-replicas-to-write` and `min-replicas-max-lag` reduce the exposure by making the master *refuse* writes when too few replicas are sufficiently caught up. That is an availability-for-durability trade, not synchronous commit: the writes it does accept are still acknowledged before replication. ## WAIT and WAITAOF: confirmation, not commit `WAIT numreplicas timeout` blocks the calling client until at least `numreplicas` replicas have acknowledged all write commands previously sent on that connection, and returns how many actually did. `WAITAOF numlocal numreplicas timeout`, added in Redis 7.0, blocks until those writes have been fsynced to the AOF on the local node and/or on that many replicas, returning both counts; it requires AOF to be enabled on the nodes being counted. Their shared limitation is that they are **post-hoc**. The write was applied and became readable before you called them. If the command returns a count lower than you asked for, nothing rolls back — you have an applied, visible, possibly non-durable write and must decide what to do (retry, alert, or fail the request while knowing the data may still be there). They are also not proof against correlated failure: if the acknowledging nodes share a rack, a power feed, or an availability zone, they can all disappear together. The cost is real. Waiting for a replica adds at least one replication round trip to the write path; `WAITAOF` additionally waits on a real fsync, which under a once-per-second policy can mean waiting for the next fsync tick. Applying either to every write turns Redis into a much slower system, so the usual pattern is to apply it selectively — to the small set of writes that carry value, or once at a batch or transaction boundary rather than per command. ## How to say it in an interview Start with "an OK is a memory-level acknowledgement", walk the four domains, then deliver the punchline: asynchronous replication means a failover can lose acknowledged writes no matter how aggressively you fsync, and `WAIT`/`WAITAOF` buy you after-the-fact confirmation with a latency bill, not a synchronous commit. Finish by naming the failure class you would actually design for.