Backpressure & Flow Control

The mismatch that breaks systems

A producer emits events at 10,000/sec; a downstream consumer can process 2,000/sec. Something has to absorb that 8,000/sec gap. With no plan, it's an in-memory queue that grows until the process runs out of memory and crashes — the worst possible place for a slowdown to surface, because by the time it's visible, it's an outage.

Backpressure: push the slowdown somewhere survivable

Backpressure is any mechanism that signals "slow down" back toward the producer instead of silently absorbing unlimited work. Concretely: a bounded queue that blocks or rejects once full (TCP does this at the socket level — a full receive buffer stalls the sender), a rate limiter that returns 429 instead of queuing indefinitely, or a pull-based protocol where the consumer explicitly requests the next batch (Kafka consumers do this — nothing is pushed faster than a consumer's own offset commits allow).

Push vs pull changes who's in control

Push systems are simple until the consumer can't keep up — then every unbounded push model needs backpressure bolted on after the fact. Pull systems build the limit in from the start: the consumer only gets what it asks for, so it can never be overwhelmed by more than its own request size. This is why many high-throughput systems (Kafka, reactive streams) default to pull or request-based flow, rather than push-and-hope.

Deciding what to do when you're full

Once a buffer is bounded, something must happen when it's full: block the producer (correct but can cascade the slowdown upstream), drop new or oldest items (fine for metrics/telemetry, unacceptable for financial events), or reject with a signal the caller can retry later (an explicit 429/503 beats a silent timeout). There's no universally right choice — the right one depends on whether losing an item is worse than slowing down the whole pipeline.

Remember this

• Someone must absorb a producer/consumer speed mismatch — backpressure decides who, deliberately.
• Pull-based consumption builds the limit in; push-based systems need backpressure added after the fact.
• When a bounded buffer fills, block/drop/reject is a product decision, not just an engineering one.