According to the dev.to writeup, the head-of-line delay on a connection scales with the total response bytes for every command in the batch, including the commands from whatever batch previously held that connection [7]. That makes latency a property of the connection's recent history rather than of your batch. It couples call sites that share nothing at the application layer.
The arithmetic is worth doing before you tune anything. The post puts amplification at 3 to 5 writes per logical operation, which turns 5,000 requests per second against one node into 15,000 to 25,000 write commands per second [3]. Spread the top of that range across the ten-connection pool in the article's scenario and you get 2,500 commands per connection per second, an average of 400 microseconds of connection time per command before anything queues [1]. The example session write issues four commands, so at 5,000 logins per second it lands at 20,000 per second [2], and fifty goroutines against ten connections is five-to-one oversubscription with 80 percent of callers parked [3].
These are illustrative numbers, sketched from the scenario rather than pulled off a benchmark run. There is no benchmark table in the piece, and the ten-connection pool is one scenario the author built for illustration; it is not described as the client's actual default [6]. The 400 microsecond figure also assumes commands spread evenly and nobody waits, which is the assumption the fifty-goroutine case exists to break [6]. To transfer it you would need the same single-node topology [3], a comparable AOF fsync policy, and response payloads small enough that the ordering constraint rather than the bytes dominates [7].
What I would take without measuring is the ordering of failures. A pipeline's p99 tracks its slowest command; the average barely matters [9]. In the example, four commands flush together and the ZADD at the end is the one exposed to a TCP retransmit or a server-side fsync stall; when it waits, the HSET, INCR and LPUSH responses wait behind it [8][9]. Note where the amplification comes from in the first place: the inference-cache pattern writes three keys to store one prompt-response pair, and one of the three exists so that billing works [12].
The prescription is to group commands by latency sensitivity rather than by logical operation, with a synchronous class for anything whose response the caller needs before returning, such as the rate-limit increment [11]. The material stops before the second class is defined, so I will not guess at it. The boundary rule stands without it. Draw the pipeline around what the caller must wait for, not around what the handler happens to touch. In my context that means the login-event push and the expiry-index update leave the request path, and the tail stops depending on which command drew the unlucky connection [8][9].
