# Diagnosing pipeline latency confusion on Upstash
## Symptom
You pipelined 50 commands expecting each to be fast, but the first
result arrives no sooner than if you had run them one by one. Or:
batching made P99 worse.
## Cause
The docs call this out: the latency of each command in a pipeline
equals the total latency of the whole pipeline. Pipelining saves
round trips, which raises throughput, but no individual command
finishes before the batch does.
## When pipelining helps
- Fire-and-forget writes: 50 SETs in one HTTP request.
- Independent reads where you need all results before proceeding.
- Cutting billed requests and round trips on high-latency links.
## When it hurts
- You need the first result to decide the next command. Dependent
commands cannot pipeline at all: each needs the previous result.
- Interactive flows where the user waits on result 1 of 50. Send
the critical command alone, pipeline the rest.
- Tiny batches over an already-fast link: the batching overhead can
exceed the savings.
## Confirm
Time one /pipeline call with N commands versus N sequential calls.
The pipeline total should be much lower than the sequential total,
while any single commands latency inside the pipeline is roughly the
pipeline total.
## Fix and verify
Split critical-path commands out of the batch. Re-measure: time to
first result drops, total throughput stays high.