Bounded Queue
A queue with a maximum depth, which converts unbounded latency growth into an explicit rejection you can control.
An unbounded queue does not prevent overload; it hides it. Work accumulates, memory grows, and latency rises until every item in the queue has already timed out at its client — at which point the system is spending 100% of its capacity producing results nobody is waiting for.
Bounding the queue forces a decision at the moment of overload, and there are only four possible policies: block the producer (backpressure), reject the new item (load shedding), drop the oldest (useful for telemetry and live data where freshness beats completeness), or drop by priority.
Choosing the bound is the interesting part. Little's Law gives it: at the maximum latency you are willing to serve and the throughput you can sustain, queue depth = throughput × acceptable wait. A service handling 1,000 requests per second that must answer within 200 ms should not have more than about 200 items queued — anything beyond that is guaranteed to be answered late.
The common mistake is a bound chosen for memory safety, typically thousands of items, which is far too deep to bound latency and therefore provides no useful backpressure at all.