How do you choose the batch size when pipelining commands to Redis, and which client-side and server-side limits does an oversized batch run into?

## Why there is a ceiling at all Pipelining wins by removing round trips, and that win saturates. Going from depth 1 to 16 typically multiplies throughput several-fold; going from 1,000 to 100,000 buys almost nothing, because at that point the limits are CPU, bandwidth, and memory rather than RTT. Meanwhile the costs of depth grow linearly. So the sizing question is really: what is the smallest batch that captures the RTT saving, and what breaks if I go far beyond it? ## Server-side limits **Query buffer.** Each client connection has an input buffer where bytes accumulate until complete commands can be parsed. A pipelined write lands there in bulk. `client-query-buffer-limit` (default 1 GB) caps it; a client that exceeds it is closed with an error, and you will see it in the log and in `CLIENT LIST` as a growing `qbuf`. A single argument is separately capped by `proto-max-bulk-len` (default 512 MB), which matters when the batch contains large values rather than many small commands. **Output buffer.** Replies are appended to a per-client output buffer and drained as the socket becomes writable. This is the dangerous one: `client-output-buffer-limit normal 0 0 0` means normal (non-replica, non-pubsub) clients have **no** hard limit, soft limit, or soft seconds. If the client keeps writing commands and never reads, the server keeps buffering replies in RAM. A million `GET`s of 1 KB values is a gigabyte of reply buffer attributed to one client, which can trip `maxmemory` behaviour, trigger evictions, or push the process into the OOM killer. `CLIENT LIST` shows this as rising `omem`, and `INFO clients` reports `client_recent_max_output_buffer`. **Fairness and latency.** Redis executes commands one at a time on a single loop. A huge readable batch means a long uninterrupted stretch of work for one client, during which every other client waits. This inflates p99 latency across the whole instance and can show up as unrelated timeouts. Splitting the same work into moderate batches interleaves naturally. ## Client-side limits The client must retain one entry per in-flight command so it can match replies positionally, so deep pipelines cost client memory too, and many drivers buffer the entire outgoing batch before writing. Deferring all reply parsing to the end also means an error at command 7 is not noticed until command 1,000,000 has already been sent. Some drivers additionally have a per-request write timeout that a huge single write can exceed. A related trap is **flow-control deadlock reasoning**: people assume that if the client stops reading, TCP back-pressure will simply pause the server. It does not translate into safety, because the server absorbs the back-pressure as heap memory in the output buffer rather than blocking, which is precisely why unbounded batches turn into memory incidents. ## A practical sizing method 1. Estimate bytes, not commands: `batch_bytes = N x (avg request size + avg reply size)`. Target something on the order of hundreds of KB to a few MB per flush. 2. Start at 100-1,000 commands per flush, measure end-to-end throughput and the instance's p99 latency, and stop increasing when throughput flattens or other clients' latency degrades. 3. **Read replies as you flush.** Streaming (write batch, read batch, repeat) keeps both buffers bounded and surfaces errors early. 4. For bulk import, use `redis-cli --pipe`, which streams raw RESP and reconciles reply counts and errors at the end. 5. Watch `CLIENT LIST` (`qbuf`, `qbuf-free`, `omem`, `age`), `INFO clients`, and the slow log while tuning. 6. Prefer variadic commands (`MSET`, `MGET`, multi-member `SADD`) where they apply: same round-trip saving, fewer commands to buffer, and one execution unit. ## Sharded and replicated deployments When many keys are involved you cannot always keep one flat batch, because commands must be routed per destination; drivers typically split the batch per connection and re-merge the replies. That splitting also naturally bounds per-connection batch size. Independently, all those writes still propagate to replicas and the AOF, so a huge burst can spike replication backlog use and disk write pressure, which is another reason to smooth rather than spike. ## What an interviewer is listening for That you size by bytes and measured effect rather than folklore, that you know the reply side is the memory risk because normal clients are unlimited by default, and that you connect oversized batches to *other* clients' latency, not just your own throughput.