Backpressure Explained: What to Do When Producers Outrun Consumers

A producer that makes work faster than a consumer can handle it isn’t a bug, it’s a normal condition in any system with more than one moving part. What determines whether that’s a non-event or an outage is whether the system has backpressure: some mechanism for the consumer to signal it can’t keep up, and for the producer to actually respond to that signal instead of continuing to fire at full speed into a queue that’s about to run out of memory.

The three options, and why “just buffer more” isn’t one of them

When a producer outruns a consumer, a system has exactly three real choices:

1. Buffer the excess. Hold the extra work somewhere until the consumer catches up. This works as long as the mismatch is temporary and the buffer has a bound.
2. Drop some of it. Discard work that can’t be handled in time, either the newest arrivals or the oldest waiting ones, depending on which matters more for your use case.
3. Push back on the producer. Signal the producer to slow down or stop, so work never enters the system faster than it can be processed.

“Just add a bigger buffer” is the answer teams reach for by default, and it’s the one that fails worst. An unbounded buffer doesn’t solve the mismatch, it just delays the failure and makes it bigger. If a consumer is permanently, not just temporarily, slower than the producer, the buffer grows without limit until the process runs out of memory and crashes, at which point every message in that buffer is lost at once, along with whatever else was running in that process. A dead letter queue handles the case where individual messages fail processing; backpressure handles the case where the rate of incoming work outpaces the rate of processing, which is a different problem and needs a different mechanism.

Backpressure already exists in your stack, probably

Several layers of common infrastructure implement backpressure natively, which means the right first move is often “use the mechanism that’s already there” rather than building a custom one.

TCP has a receive window: the receiver advertises how much unacknowledged data it can buffer, and the sender throttles to match. If your application isn’t reading from a socket fast enough, the window shrinks and the sender’s throughput drops automatically, no application code required.

Node.js streams implement backpressure through the write() return value and the drain event:

function writeData(writable, chunks) {
  let i = 0;

  function write() {
    let ok = true;
    while (i < chunks.length && ok) {
      // write() returns false when the internal buffer is full
      ok = writable.write(chunks[i++]);
    }
    if (i < chunks.length) {
      // paused: wait for 'drain' before writing more
      writable.once('drain', write);
    }
  }

  write();
}

Ignore the false return value and keep calling write() anyway, and Node buffers everything in memory regardless, silently defeating the backpressure the stream API was designed to provide. This is the most common way teams accidentally build an unbounded buffer without meaning to: the mechanism is right there, and the code just doesn’t check it.

Reactive libraries (RxJS, Project Reactor, Akka Streams) build backpressure into the subscription model itself, where a subscriber requests a specific number of items and the publisher is contractually bound not to send more than requested until asked. This pushes the buffer-or-drop decision to whoever’s writing the subscriber, instead of leaving it implicit.

When there’s no native mechanism: queues and explicit limits

Message queues need an explicit bound and an explicit overflow policy, because most queue implementations will happily grow unbounded by default.

import queue

# A bounded queue: put() blocks once full, applying natural backpressure
# to whatever is producing into it.
work_queue = queue.Queue(maxsize=1000)

def producer(item):
    # blocks here if the queue is full, which is the point:
    # the producer's own thread slows down to match consumption
    work_queue.put(item, block=True, timeout=5)

Blocking put() is backpressure in its simplest form: the producer’s own code pauses until there’s room. For a producer you don’t control, or where blocking indefinitely isn’t acceptable, the timeout plus an explicit overflow policy (reject, drop-oldest, or route to a separate low-priority path) makes the failure mode a decision instead of an accident.

HTTP APIs: 429 is backpressure

At the API boundary, backpressure looks like a status code. When a service is at capacity, the correct response isn’t to accept the request and let latency degrade for everyone, it’s to reject it explicitly:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{"error": "rate_limit_exceeded", "retry_after_seconds": 30}

A well-behaved client reads Retry-After and backs off accordingly. That’s the request/response version of a downstream consumer telling an upstream producer to slow down, functionally identical to a TCP receive window or a false return from stream.write(), just expressed at the HTTP layer instead of the transport or process layer. For clients you don’t control and can’t trust to honor the header, pair this with an API gateway or load balancer rate limit as a hard backstop, since Retry-After is a request, not an enforcement mechanism.

Picking a strategy for your actual system

Situation	Reasonable default
Temporary burst, consumer catches up quickly	Bounded buffer, sized to the expected burst
Consumer permanently slower than peak producer rate	Push back on the producer (block, 429, or reject)
Losing some data is acceptable, staying responsive isn’t	Drop-oldest or drop-newest with metrics on drop rate
Producer is external and doesn’t respect signals	Bounded buffer plus a hard rate limit at the edge

The wrong choice usually isn’t picking the wrong strategy, it’s not picking one at all and letting an unbounded buffer become the default by omission. If you’re reviewing a system for where load spikes turn into outages, an unbounded queue or a stream write path that ignores its own backpressure signal is one of the first places worth checking, and our team has found exactly that gap during more than a few production incident reviews.