Streaming trade-offs, backpressure, and cancellation
Why streaming is powerful, why mature teams avoid it by default, and what gets harder once a call stays open.
Your win: explain when streaming is worth it, what operational complexity it adds, and why unary is still the right default surprisingly often.
In plain English Plain English: streaming is great when the data really arrives as a sequence over time, but it creates a longer-lived conversation that is harder to budget, cancel, and debug.
The problem: streaming changes the shape of the whole call
With unary, the call starts, does one unit of work, and ends. With streaming, the call stays open. That changes cancellation, buffering, backpressure, observability, and operational failure modes.
That is why senior engineers usually do not talk about streaming as a feature list. They talk about stream lifecycle: how long it lives, who owns it, how it ends, and what happens when one side slows down or disappears.
The rule to memorise Use streaming when the data shape is a real sequence or live feed — not just because streaming sounds more advanced.
What gets harder
This is the honest cost side of the trade-off. The feature is real, but so is the operational weight that comes with it.
reasoning about how long the call should live
handling partial progress and mid-stream failure
backpressure and buffering between sender and receiver
debugging which side stopped consuming or producing
making cancellation actually stop ongoing work
Anchor — the honest repo story The repo’s main three services stay unary. Streaming examples live in tom and bob, and there is no bidi example at all. That honesty is useful: it shows that many production systems deliberately prefer unary unless the sequence really matters. “We know streaming, but we do not force it everywhere” is often the more senior answer.
Common mistake Reaching for streaming because the payload is large or because multiple messages exist, when a paginated or batched unary design would be simpler to operate.
Read this next
gRPC core concepts + streaming tutorials
Use the official RPC-type docs, but read them through the lens of lifecycle and operational cost.
Choose streaming because the data shape needs it, not because the feature exists.
Why do many teams still prefer unary even after learning streaming?
recall, then click to reveal
Because unary is shorter-lived, easier to budget and retry, easier to debug, and usually enough unless the business problem is naturally a sequence or live feed.
Want a senior comparison of “batched unary vs stream” for one concrete use case, with the decision argued step by step? Ask me.