Backpressure

WHY IT EXISTS Components in a pipeline rarely process work at identical rates. When a producer outpaces a consumer, the imbalance has to go somewhere; without control it accumulates in unbounded buffers, consuming memory until the process is killed or latency becomes useless. Backpressure exists to make that imbalance visible and to bound it.

THE MENTAL MODEL Picture water flowing through pipes of different widths. If a downstream pipe narrows, pressure builds backward toward the source, and the source must reduce flow. In software the source is a producer, the narrow pipe is a slow consumer, and the pressure is a signal to slow down, buffer with limits, or shed load.

HOW IT WORKS Several mechanisms implement it. Bounded queues block or reject when full, forcing the producer to wait. Reactive-streams protocols let the consumer explicitly request n items, so the producer never sends more than demand. At the network layer, TCP flow control shrinks the receive window. When slowing is impossible, systems shed load by dropping or rejecting requests, trading completeness for survival.

WHEN IT MATTERS It matters in any streaming or event-driven system, message queues, async I/O pipelines, and microservice chains where one slow dependency can otherwise cascade into memory exhaustion across the fleet.

ONE CONCRETE EXAMPLE A service reads from a Kafka topic and writes to a slow database. With no backpressure it keeps polling and buffering records in memory until the heap fills and it crashes, lagging the topic for everyone. Adding a bounded in-flight limit so it only fetches more records after writes drain keeps memory flat; the consumer simply reads slower, lag stays observable, and the service stays alive under the spike.