When Redis documentation calls a MULTI/EXEC transaction atomic, exactly which guarantees does that cover — with respect to other clients, to a crash, and to replicas?

## The guarantee that is real: isolation Redis executes commands from all clients on a single thread. When EXEC arrives, the server takes the queued commands and runs them one after another as a single unit of work; it does not return to the event loop to serve another client in the middle. The consequences are strong and easy to state: - No other client's command can observe the keyspace between two commands of the transaction. - No other client's write can land in the middle of the transaction and be overwritten by half of it. - Every external observer sees either the pre-transaction state or the post-transaction state. That is the entire value proposition of MULTI/EXEC over sending the same commands one at a time or in a plain pipeline. Pipelining reduces round trips but allows interleaving; EXEC does not. It is worth being precise that this isolation covers only the execution window. Anything you read *before* MULTI can be stale by the time EXEC runs, unless you also WATCH the keys involved. ## The guarantee that does not exist: atomicity in the rollback sense In a relational database, "atomic" carries the promise that a failed statement can undo the whole unit. Redis does not keep an undo log, so if a queued command fails at execution time, the commands around it still take effect and stay. The only all-or-nothing case is a command rejected at queue time, which makes EXEC abort before running anything. Using the word "atomic" for both properties is the source of most confusion here; when answering, separate them explicitly: **grouped and uninterrupted, yes; revertible, no.** ## Durability is a separate axis entirely EXEC returning its reply array means the commands were applied to the in-memory dataset. It says nothing about disk. - With **no persistence**, a crash loses everything since the last restart, transaction or not. - With **RDB snapshots only**, you lose everything written since the last snapshot — potentially minutes. - With **AOF and `appendfsync everysec`** (the common default), the transaction is written into the AOF buffer and fsynced at most a second later; a power loss in that window loses it even though EXEC succeeded. - With **AOF and `appendfsync always`**, the write is fsynced before the reply, at a substantial throughput cost. One useful property: the transaction is propagated to the AOF as a single `MULTI ... EXEC` block, so on reload the batch is replayed as a unit rather than partially. If a crash truncates the AOF mid-block, `redis-check-aof` trims the incomplete tail, so you lose the whole transaction rather than half of it. The block-level integrity is preserved; the survival of the block is not guaranteed. ## Replication is asynchronous A primary applies the transaction, replies to the client, and propagates it to replicas afterwards — again wrapped in a MULTI/EXEC block so a replica never applies a partial batch. But there is a window in which the primary has acknowledged and no replica has the data. If the primary dies in that window and a replica is promoted, the committed transaction is gone from the surviving dataset, and a client that read its own write can observe it vanish. `WAIT numreplicas timeout` blocks until the given number of replicas have acknowledged the writes so far, which shrinks the window, but it is not a consensus commit: it can time out, and it cannot rule out a failover to a replica that lagged. `min-replicas-to-write` / `min-replicas-max-lag` make the primary refuse writes when too few replicas are keeping up, converting silent loss into a visible error. Neither turns Redis into a strongly consistent store; if the data cannot tolerate loss on failover, Redis is the wrong system of record for it. ## The cost side of running as one unit The same single-threaded execution that provides isolation makes a large transaction a latency event: while EXEC runs, no other client is served. A transaction containing thousands of commands, or one containing an O(N) command over a big collection, produces a stall visible to everyone and shows up in SLOWLOG under EXEC. Keep transactions small and bounded, and prefer many small units over one giant batch unless the isolation genuinely requires the batch. Memory matters too: the queue is held on the connection until EXEC, so an enormous queued batch consumes memory on the server before it does anything useful. ## Answering the question well A strong answer states the three axes separately: **isolation** — yes, guaranteed by the single execution thread; **rollback** — no, by design, with only the queue-time abort as an all-or-nothing case; **durability and replication** — orthogonal, governed by persistence configuration and by asynchronous replication, so EXEC succeeding is not a promise the data survives a crash or a failover.