What Is Backpressure?

What is backpressure?

The term is borrowed from fluid dynamics: resistance downstream pushes back on flow upstream. In software, the underlying problem is a rate mismatch — a producer emits events faster than a consumer can process them, either transiently (a traffic spike) or persistently (an under-provisioned consumer). Without flow control, the excess accumulates in buffers, memory grows, latency climbs, and the system eventually collapses or starts dropping data uncontrollably.

How backpressure is expressed depends on whether the system is push-based or pull-based. Push-based systems need an explicit signal: in the Reactive Streams specification, a subscriber calls request(n) to grant the publisher permission to send n more elements; stream processors like Apache Flink use credit-based flow control between operators. Pull-based systems get backpressure implicitly: a Kafka consumer simply polls at its own pace, and unread messages accumulate as consumer lag on the broker rather than as memory in the consumer.

When the source cannot be slowed — market data feeds, sensor streams, user clicks — backpressure alone is not enough. The complementary strategies are buffering (absorb bursts), load shedding (drop work by policy), sampling (process a subset), and scaling out consumers.

How backpressure works

Credit-based flow control in a streaming job illustrates the mechanics end to end:

1. 1.A sink stage slows down — say its database writes start taking longer.
2. 2.The sink's input buffers fill, and it stops granting credits to the operator upstream of it.
3. 3.That operator can no longer send, so its own buffers fill, and it in turn withholds credits from its upstream — the pressure propagates stage by stage toward the source.
4. 4.The source stops pulling from the message broker. Unconsumed events now accumulate as broker-side lag — durable and bounded by disk — instead of as in-memory buffers inside the job.
5. 5.When the sink recovers, credits flow again and the pipeline drains the accumulated lag.

The same pattern exists at every layer: TCP's sliding receive window is backpressure between two network hosts, and bounded queues between threads are backpressure inside a single process. Frameworks differ mainly in where pressure is absorbed — Kafka and Flink make characteristically different choices about broker-side versus operator-side buffering.

Why backpressure matters in real-time systems

Backpressure converts an overload problem into a freshness problem. That is its virtue and its cost: the pipeline survives the spike, but its output now trails reality. Every event sitting in broker lag is an event the downstream state does not yet reflect.

For automated decisioning, this is the part that deserves attention. Derived state — velocity counters, running aggregates, feature values — is maintained by exactly the kind of pipeline that backpressure protects. During a sustained spike, that state can fall seconds or minutes behind the events it summarizes, and any decision reading it acts on the past. The lag is invisible unless measured, which is why consumer lag is best treated as a staleness metric, not just a throughput metric — a distinction explored in data freshness vs latency. A pipeline can have excellent per-event latency in steady state and still deliver badly stale state during precisely the bursts when decisions matter most.

There is also a recovery consideration: when pressure releases, the pipeline drains its backlog at maximum rate, which can itself overwhelm downstream systems. Mature designs bound the drain rate rather than letting the flood through at once.

FAQ