While one Redis client is sending a batch of commands in a single pipeline, can another client's commands execute in between them? State precisely what guarantees pipelining does and does not give.

## The mental model: one shared execution queue Redis processes client work on a single command-execution loop. Each connected client has its own input (query) buffer and output buffer. The server repeatedly picks up readable connections, parses **complete** commands out of each query buffer, executes them, and appends replies to that client's output buffer. Nothing in this design associates a group of commands with a client 'turn'. Pipelining changes only how the bytes arrived; the scheduler still moves between clients at command granularity. The consequence is direct: if client A pipelines `[C1, C2, C3]` and client B sends `X`, a legal execution order is `C1, X, C2, C3`. There is no fencing, no per-key lock, no batch boundary the server is aware of. From the server's perspective a pipeline is indistinguishable from the same commands arriving separately but quickly. ## The guarantees you do get 1. **Ordering within the connection.** Commands from one connection execute in the byte order they were written. Redis will never run C2 before C1. 2. **Reply ordering.** Replies are appended to the output buffer in execution order, so the *n*th reply answers the *n*th command. This is what lets clients pop a pending-command queue positionally instead of correlating IDs. 3. **Per-command atomicity.** Each individual command is still indivisible, as always in Redis. `INCR` inside a pipeline is exactly as atomic as `INCR` alone. The atomicity boundary is the command, not the batch. ## The guarantees you do not get - **No isolation.** Read-then-write logic split across two pipelined commands is a classic race: two clients both pipeline `GET counter` and `SET counter <value+1>` and one increment is lost. Pipelining actually widens nothing, but it also fixes nothing; people wrongly assume the batch is protected. - **No all-or-nothing on failure.** If the socket breaks, the process is killed, or the server fails over mid-batch, a prefix of the commands has run. Worse, the client may not know how long that prefix is, because the replies it never read may still have been produced. Pipelined batches should therefore be composed of idempotent commands (`SET` of an absolute value rather than `INCRBY`, where possible), or be replayable. - **No error short-circuit.** A command that errors returns an error reply and the batch continues. If command 3 returns `WRONGTYPE`, commands 4 onward still execute. Clients that ignore replies silently swallow such errors, which is one of the most common production bugs around pipelining. - **No cross-client ordering.** Two clients pipelining concurrently interleave arbitrarily. Do not use pipeline boundaries to reason about relative ordering between clients. ## Getting indivisibility when you need it - **`MULTI` ... `EXEC`.** Commands issued after `MULTI` are queued server-side and executed as one uninterrupted unit at `EXEC`; no other client's command runs inside that unit. The transaction and the pipeline are orthogonal and are usually combined: send `MULTI`, the commands, and `EXEC` in one pipelined write so you also save the round trips. - **`WATCH` plus `MULTI`/`EXEC`** for check-then-act on a key, which is the optimistic-concurrency form: `EXEC` returns a null reply if a watched key changed. - **Lua scripts / Functions** when the batch needs to *branch* on a value it read, since a transaction cannot look at intermediate results. ## Diagnosing the misconception in practice Symptoms of assuming pipeline atomicity are lost updates under load, counters that drift, and 'impossible' interleavings in logs. A quick test: run the suspect batch from two clients in a tight loop and assert the invariant; it will break within seconds. The fix is almost never a bigger pipeline, it is choosing the right unit of atomicity, which is a single command, a `MULTI`/`EXEC` block, or a script. ## What an interviewer is listening for A crisp separation of two ideas: **batching bytes** (pipelining) versus **batching execution** (transactions/scripts). Candidates who conflate them tend to ship read-modify-write races. Bonus points for mentioning partial application on connection loss and that errors do not abort the rest of the batch.