Redis replicates asynchronously. When a client receives +OK for a SET command, what has actually been guaranteed, and what does the WAIT command add on top?
answer
- +OK = in primary memory only
- Propagation happens after the reply
- Loss window ~ replication lag + failover time
- WAIT n timeout returns count, never rolls back
- WAITAOF for fsync; min-replicas-to-write as precondition
basics
~20 s+OK means only that the write was applied in the primary's memory. Replicas are sent the write after the reply, so an acknowledged write can vanish if the primary dies before propagating and a replica is promoted. WAIT numreplicas timeout blocks until that many replicas acknowledge the offset and returns how many did; it never rolls anything back.
solid answer
~60 sA Redis primary applies the command, replies to the client, and only then propagates it to replicas and (depending on `appendfsync`) to disk. So `+OK` guarantees just one thing: the write is in the primary's memory and visible to subsequent reads on the primary. It says nothing about durability on disk or presence on any replica. The consequence is a real data-loss window. If the primary crashes before the write reaches a replica, and failover promotes that replica, the acknowledged write is gone; if the old primary later rejoins as a replica, it discards its extra data during resynchronization. `WAIT <numreplicas> <timeout>` narrows the window: it blocks the calling client until at least that many replicas have acknowledged the current replication offset, returning the count actually reached. It is not a transaction and does not roll back on shortfall, since the write already happened and may still propagate later. It also costs a round trip. `WAITAOF` (Redis 7.0) does the same at fsync granularity, and `min-replicas-to-write` with `min-replicas-max-lag` refuses writes up front when too few replicas are in touch.
code
text · 14 lines> SET order:9001 paid
OK # in primary memory only
> WAIT 2 1000 # want 2 replicas within 1s
(integer) 1 # only 1 acknowledged; the write still stands
# fsync-level acknowledgement, Redis 7.0+, AOF required
> WAITAOF 1 1 1000
1) (integer) 1 # local fsyncs
2) (integer) 1 # replica fsyncs
# refuse writes when fewer than 2 replicas are within 10s of lag
> CONFIG SET min-replicas-to-write 2
> CONFIG SET min-replicas-max-lag 10go deeper
Recall that replication is asynchronous, so a successful reply only means the primary applied the write in memory, and a crash can lose it.
Explain the ordering (apply, reply, then propagate), the failover loss window, and that WAIT blocks for replica acknowledgements and returns a count.
Add the precise non-guarantees of WAIT, its latency cost and selective use, WAITAOF for fsync-level acks, and min-replicas-to-write as an availability-versus-durability precondition.
Frame the whole thing as a design boundary: Redis trades durability for latency by construction, so decide which writes may be lost, keep the true source of truth elsewhere for the rest, and bound the exposure by controlling lag and failover time.
## What the acknowledgement means Redis processes a write by mutating its in-memory data structure, appending the effect to the replication stream and (if AOF is on) to the AOF buffer, and then sending the reply. Propagation to replicas happens asynchronously afterwards, and fsync of the AOF happens according to `appendfsync` (typically once per second). So `+OK` means: applied in memory on this primary. Nothing more. This is a deliberate design choice; Redis buys its latency profile by not waiting on disk or on the network before answering. ## The loss window, concretely Suppose a client sets a key and receives +OK, and 5 ms later the primary's host dies. The replica has not received the write. A failover promotes the replica, clients reconnect to it, and the key is simply absent, even though the application was told the write succeeded. When the old primary comes back and is reattached as a replica, it synchronizes from the new primary and drops the divergent write. This is not a bug; it is the definition of asynchronous replication, and it is why Redis is described as not providing strong consistency. The size of the window is roughly the replication lag plus the failure-detection and promotion time. The general theory of durability tradeoffs is not the point here; what matters for Redis is that the acknowledged-but-unreplicated set is bounded by lag, so lag is what you monitor and control. ## What WAIT does `WAIT numreplicas timeout` blocks the calling connection until at least `numreplicas` replicas have acknowledged a replication offset at least as high as the one the client's last write produced, or until the timeout (milliseconds; 0 means wait forever). It returns the number of replicas that acknowledged, which may be fewer than requested if the timeout fired. Internally the primary asks replicas to ACK immediately rather than waiting for the usual one-second cycle. What WAIT is not: - It is **not** a transaction or a two-phase commit. The write is already applied on the primary. If the required number is not reached, nothing is undone, and the write will very likely reach the replicas a moment later anyway. - It does **not** make the write atomic across nodes, and it does not prevent that write from being lost in an unlucky failover, because the replica that acknowledged is not necessarily the one that gets promoted. - It does **not** imply disk durability. A replica acknowledges having received and applied the stream in memory. For fsync-level acknowledgement Redis 7.0 added `WAITAOF <numlocal> <numreplicas> <timeout>`, which requires AOF enabled and returns the counts of local and replica fsyncs achieved. What WAIT buys is a genuinely reduced loss window for the specific writes you care about, at the price of one extra round trip of latency, so it is used selectively (after the payment record, not after every cache fill) rather than globally. ## The complementary guardrail `min-replicas-to-write N` with `min-replicas-max-lag M` makes the primary refuse writes entirely when fewer than N replicas have acknowledged within the last M seconds. That is a coarse, always-on precondition rather than a per-write acknowledgement: it converts a silent durability risk into a visible write outage, which is a deliberate availability-versus-durability choice. Combining it with WAIT on critical paths is common; combining it with nothing and assuming Redis will not lose acknowledged writes is the mistake interviewers listen for. ## How to answer well State the guarantee precisely (in-memory on the primary), name the loss window and what bounds it (replication lag, failover time), then describe WAIT as a narrowing tool with explicit non-guarantees, and mention WAITAOF and min-replicas as the other two levers. Finish with the honest conclusion: if your workload cannot tolerate losing an acknowledged write at all, Redis replication is not the mechanism that will give you that.
- WAIT 2 1000 returns 1. What should the application do?Decide based on the business meaning, because Redis will not undo anything and the write may replicate a moment later. Typical responses are to log and alert (replication is degraded), to avoid depending on that write surviving a failover, or to write the record to a durable store as the source of truth and treat Redis as derived. What you must not do is assume the write failed and blindly retry as if nothing happened, since a non-idempotent retry now double-applies.
- Does using WAIT make Redis strongly consistent?No. It reduces the window in which an acknowledged write exists only on the primary, but the replicas that acknowledged are not guaranteed to be the ones promoted, and a partitioned old primary can still accept writes until it notices. It is a probabilistic improvement in durability, not a consensus protocol, and Redis documentation is explicit that replication does not provide strong consistency.
saying these in an interview costs you the question
- Saying +OK means the write is on disk or on the replicas
- Describing WAIT as making the write synchronous or transactional
- Believing WAIT rolls back or cancels the write when the target count is not met
- Assuming a replica acknowledgement implies an fsync to disk
- Claiming min-replicas-to-write prevents any acknowledged-write loss