An unbounded queue turns a failure into a latency collapse (Little's law: L = λW; as the queue grows, response time grows at the same λ).
A buffer and backpressure are not alternatives on a single scale. Overload protection is assembled from four different things: a bounded buffer (absorbs a burst, but not a trend), a concurrency limit and admission control (decide how much work to accept at all), backpressure (pushes the pressure back to where the work came from), and load shedding (fast rejection where there is nowhere to push the pressure). The choice between the last two comes down to one question: can the producer slow down? An internal service on a gRPC stream can; a random user’s browser cannot, and for it the honest answer is 429 with Retry-After, not a thirty-second place in a queue. An end-to-end deadline and a retry budget (24) are part of the same design: without them, shed load comes back as retries and finishes off what you were protecting.
// bounded channel + rejection instead of a growing queue
select {
case jobs <- j:
case <-time.After(50 * time.Millisecond):
return ErrOverloaded // load shedding: a fast failure beats a slow success
}// Reactive Streams: backpressure in the contract; or a bounded executor
var pool = new ThreadPoolExecutor(8, 8, 0, SECONDS,
new ArrayBlockingQueue<>(1_000), // bounded!
new ThreadPoolExecutor.CallerRunsPolicy()); // pressure back onto the producer// bounded mpsc; send().await is itself the backpressure
let (tx, rx) = tokio::sync::mpsc::channel::<Job>(1_000);
if tx.try_send(job).is_err() { return Err(Error::Overloaded) }# bounded queue; put() suspends the producer — that is a feature
queue: asyncio.Queue[Job] = asyncio.Queue(maxsize=1_000)
await queue.put(job) # blocks when full — pressure flows back up the pipeline