Pipelining And Output Buffers Practice

Throughput improves and memory is unaffected, because replies stream to the socket as fast as they are produced.

Nothing improves, because the server always waits for each reply to be read before executing the next command.

Round-trip overhead improves, but server-side output buffers can grow if the client does not read replies.

Per-command latency improves, but the batch loses its ordering guarantee across the thousand commands.

Pipelined batches are atomic, because the server executes the whole batch before serving any other client — the batch boundary is inferred from the moment replies stop being read.

Replies are queued in the same per-connection execution order, but other clients can still interleave between commands so the batch is not atomic.

Order is preserved by sequence numbers in each RESP reply, which the client library uses to reorder responses.

Order holds only when commands touch different keys; same-key commands may be reordered for efficiency.

Wait for the fourth to complete, so all commands from one read execute together as a unit.

Execute the three complete commands, then discard the partial bytes since the client will resend the whole fourth command.

Execute only the first command per loop iteration, spreading the rest across later iterations for fairness.

It should parse and dispatch the three complete commands, then leave the partial fourth command buffered for later bytes.

Disconnecting prevents unbounded memory growth for a client that cannot consume pushed messages.

Keeping it is actually safer, because Pub/Sub buffers drop oldest messages automatically once they fill.

The server should pause all publishers until the slow subscriber catches up, preserving full delivery.

The server should spill that client's buffer to disk, so memory is protected without losing the connection.

Command handlers should retry their own writes, so transport errors map back to the command that produced the data.

Client output buffers should handle partial writes; command handlers produce replies and the database should not know socket state.

The database should track unflushed replies per key, so a failed delivery can roll the mutation back.

The kernel handles it already, since a second write resumes where the first stopped and needs no state in Redis, just as it does for files opened in append mode.