One write in a run of two hundred sent to a volatile tier without waiting for replies fails — what happened to the others?

## What the mechanism actually is Sending a run of operations without waiting for each reply is a change to **when the caller reads**, and nothing else. Instead of write-read, write-read, write-read, the caller writes all two hundred operations onto the connection and then drains two hundred replies. The saving is real and large — two hundred round trips become one — and it is bought entirely on the network, not in the store. Nothing in that description changes how the server treats the operations. It received two hundred independent operations and executed two hundred independent operations. Reply 100 carries an error; replies 1-99 and 101-200 carry whatever those operations produced, and their effects are in the keyspace. ## The three things it does not buy 1. **No all-or-nothing outcome.** No undo is recorded for an operation that already ran, so there is nothing to roll back to. Whatever applied stays applied. 2. **No isolation.** The run does not reserve the keyspace, the connection or the server. Nothing prevents another caller's operations from executing between yours, and whether one connection's buffered operations happen to run consecutively is an implementation detail that varies between stores — it is not a property you may design against. 3. **No pre-validation.** There is no pass that inspects the run before executing it, so "the whole run was rejected because one operation was malformed" is not a behaviour of this mechanism. The positive way to say all of it: **collapsing trips buys latency, and buys latency only.** ## What a failure inside a run looks like Failures in a run come in two very different shapes, and candidates conflate them: - **A per-operation failure** — a malformed argument, an operation applied to a value whose shape does not support it, a conditional write whose condition did not hold. One reply slot carries the error; everything else is unaffected. This is the case in the question. - **A connection-level failure** — the connection drops, or the unread replies exceed what the tier will hold for that connection. Now the caller loses the **outcomes** of the whole run at once, while the operations the server already executed still applied. This is the genuinely nasty case: the caller does not know how far the run got. | | Per-operation failure | Connection-level failure | |---|---|---| | What failed | one operation | the delivery of replies | | Effects of the other operations | applied | applied, but unknown to the caller | | What the caller learns | exactly which one failed | nothing about how far the run got | | Repair | re-issue that one operation | re-issue everything that must be safe to re-issue | ## How to write code that survives this - **Read every reply.** A caller that sends two hundred operations and checks only the last one has published a silent-failure path. The per-operation outcome is the only thing the mechanism gives you; discarding it throws away its one guarantee. - **Make the collapsed writes re-issuable.** Setting a value to a known state, or an operation whose repetition is harmless, can simply be re-sent. An operation that folds the previous value into the new one — an increment, an append to a collection — cannot be blindly re-sent after a connection-level failure, because you do not know whether it already applied. - **Do not put a read-then-write dependency inside a run.** Every operation's arguments are fixed at the moment you write them onto the connection, so an operation in the run cannot use the result of an earlier one. If the logic needs that, it needs a different mechanism from the atomicity family, not a bigger run. - **Keep runs homogeneous where you can.** A run of writes that are each independently safe to re-issue is recoverable by re-sending; a run that mixes those with order-dependent work is not. ## Why interviewers ask this It separates a candidate who has read the word from one who has used the mechanism. The word used for it in most client libraries sits near words used for grouping steps together, and the two get merged into a single mental model in which "batching" implies "applied together". It does not, on any store of this class. The candidate who says "latency only — one round trip, two hundred independent outcomes, nothing rolled back, other callers may act in between" has the model right, and everything else about safe use follows from it.