Key takeaway: A queue absorbing a temporary burst is solving a real problem. A queue absorbing a sustained mismatch between production and consumption rate is just relocating the eventual failure to an unbounded buffer that will, given enough time, exhaust memory and fail anyway — with a much larger backlog to explain when it does.
Why a Queue Alone Does Not Solve a Rate Mismatch
Inserting a queue between a producer generating work and a consumer processing it decouples their timing, which genuinely helps absorb a brief burst — the producer can momentarily outpace the consumer, and the queue holds the excess until the consumer catches back up during a quieter period.
If the producer’s average rate persistently exceeds the consumer’s average processing rate — not just during bursts, but as a sustained pattern — the queue does not resolve this at all. It grows continuously, and without an explicit bound, it will eventually consume all available memory and fail, at a point in time disconnected from when the actual underlying rate mismatch began, which makes the eventual failure far harder to diagnose than if the system had signalled the mismatch immediately when it started.
What Backpressure Actually Means
Backpressure is an explicit mechanism by which a slow consumer signals back to its producer that it cannot currently keep up, so the producer can respond deliberately — slow down, reject new work, or shed load — rather than the producer continuing to push work at full rate into a queue that has no way to communicate its own limits back upstream.
| Without backpressure | With backpressure |
|---|---|
| Queue grows unboundedly during sustained mismatch | Producer is signalled and can respond |
| Failure occurs eventually, disconnected from root cause timing | Problem is visible immediately when it starts |
| Failure mode is memory exhaustion, often affecting unrelated processes | Failure mode is a deliberate, controlled rejection |
| Diagnosing requires reconstructing history from a large backlog | Diagnosing starts from the moment signalling began |
The diagnostic difference is significant in practice — a system with backpressure that starts rejecting or slowing down clearly indicates, right at the moment it happens, that the mismatch has started and roughly why. A system without it fails later, disconnected in time from the actual cause, with a large accumulated backlog that itself takes real time and effort just to work through even after the underlying rate mismatch is fixed.
Where to Actually Implement It
Bounded queues, with an explicit maximum size that causes new work to be explicitly rejected or the producer to be blocked once reached, are the most direct implementation — the bound forces the mismatch to become visible immediately as rejections or blocking, rather than allowing invisible unbounded growth.
Rate limiting on the producer side, informed by feedback from the consumer about its current capacity, prevents the mismatch from occurring in the first place rather than only detecting it once a bound is reached — this requires an actual feedback channel from consumer to producer, which is more architecture than a bounded queue alone but produces smoother behaviour than hitting a hard limit repeatedly.
Load shedding — deliberately and explicitly dropping or rejecting a portion of incoming work under sustained overload, in a controlled way with clear signalling to whoever sent the rejected work — is frequently the correct response once backpressure indicates the system genuinely cannot keep up, since continuing to accept work it cannot process in a timely manner degrades everything rather than failing a defined, bounded portion cleanly.
Recognising the Absence of Backpressure
An unbounded queue, in any part of a system, is worth treating as a specific and identifiable risk during design review — the question “what happens if the consumer falls behind and stays behind” should have a concrete, deliberate answer, and “the queue will grow” is not actually an answer, since it just defers the question of what happens once that growth reaches its inevitable practical limit.
The Bottom Line
Treat an unbounded queue as a deferred failure rather than a solved problem, and design explicit backpressure — bounded queues, producer-side rate limiting informed by consumer capacity, or deliberate load shedding — so a sustained rate mismatch is visible and handled immediately rather than discovered later as a memory exhaustion failure disconnected from its actual root cause.
