An earlier piece on this site looked at circuit breakers: the mechanism a caller uses to stop hammering a dependency once that dependency is already struggling. A breaker is remedial. It engages after a mismatch between how much is being asked and how much can actually be delivered has already turned into trouble. This piece is about the preventive counterpart — backpressure and flow control, the family of mechanisms that try to keep that mismatch from reaching the point where a breaker needs to trip at all.
Take any two components where one produces work and another consumes it — a service writing to a queue that another service reads from, a client sending requests to a server, one thread handing tasks to another. If the producer's rate ever exceeds the consumer's rate, even briefly, the difference between them doesn't vanish. It has to go somewhere, and "somewhere" is a real, physical place: a buffer, a queue, a socket's send window, a stack of pending allocations sitting in memory. An unbounded buffer looks, at a glance, like a solution — nothing gets rejected, nothing fails, every request is eventually accepted. But it hasn't fixed the rate mismatch; it has only relocated it and delayed the reckoning. Little's Law makes this precise rather than anecdotal: the average number of items waiting in a system equals the arrival rate multiplied by the average time each item spends there. If the arrival rate is sustainedly higher than the rate work actually gets done, that number climbs without bound, as a matter of arithmetic, not bad luck. What changes is only the shape of the eventual failure — instead of an immediate, cheap rejection at the front door, you get a slow, expensive one: memory that keeps growing until the process is killed for using too much of it, or a request that does eventually get served, so late that whatever needed the answer has already timed out, retried, or moved on. An unbounded queue doesn't prevent the failure the mismatch was always going to cause. It just makes it bigger and later.
Backpressure is the alternative: instead of absorbing the mismatch
silently into a growing buffer, the consumer tells the producer,
explicitly and before things break, to slow down or stop. The
distinction underneath most concrete mechanisms is between push and
pull. In a pure push system, the producer sends whatever it has,
whenever it has it, and the consumer's only options are to keep up or
fall behind into a buffer. In a pull system, the consumer requests the
next unit of work only when it's actually ready for it, so the rate is
set by the side that has to do the work, not the side generating it.
Real systems use both, deliberately. TCP's flow control is a pull
mechanism disguised as a stream: the receiver continuously advertises
a window — the number of bytes it can currently accept — and the
sender is contractually bound not to exceed it, which means the
receiver's own pace, not the sender's eagerness, governs how fast data
actually moves. The Reactive Streams family of APIs makes the same
idea explicit at the application level with a request(n)
call: a subscriber asks a publisher for exactly n items, and
the publisher may not send more than that until asked again. A bounded
in-memory queue with a blocking put() does it with the
crudest and most direct mechanism of all: when the queue is full, the
producer's own thread simply stops running until the consumer makes
room. In every case, the pressure stops being an ever-growing pile of
unprocessed work and becomes something with an actual owner: a
withheld request, a fixed window, a blocked thread.
Once backpressure activates, something concrete has to happen at the point closest to the source, and there are really only two honest answers. One is to block — make the producer wait until the consumer signals it can accept more. The other is to shed — drop something now, deliberately, rather than let everything queue up and arrive too late to matter. Shedding requires a decision made in advance about what to drop: oldest items, on the theory that a newer request is more likely to still be wanted by the time it's served; newest items, on the theory that whatever's already waited longest is closest to being useful and shouldn't be wasted; or by priority, if the system can tell requests apart at all. That's the same instinct the piece on circuit breakers made explicit for failure — decide what gets sacrificed calmly, ahead of time, rather than discovering the answer implicitly, under load, at the worst possible moment — applied here to volume instead of failure.
Blocking is more honest in one specific sense: nothing gets silently thrown away. But it has a real cost, and the cost is contagion. If a consumer blocks its own producer, and that producer is itself someone else's consumer, the slowdown can propagate backward through every synchronously connected stage, potentially all the way to wherever the work originated. That should sound familiar — it's structurally the same shape as the cascading failure the circuit-breaker piece described, one component's trouble climbing the chain to affect components that were, in isolation, perfectly healthy. The difference is that here the cascade is the mechanism working exactly as intended, not a side effect nobody chose. A chain of induced, visible slowness that everyone downstream can see and respond to is a fundamentally different thing from a chain of failure that emerged as an accident of how components happened to be wired together.
Backpressure only works if every hop in the chain actually participates. A pipeline built with careful bounded queues everywhere except one point — a fire-and-forget sensor feed, a webhook from a third party you don't control, a UDP stream with no return channel — turns the whole discipline back into an unbounded buffer exactly at that one point, because there's no way to tell that source to slow down. The chain is only as good as its least cooperative link. For sources that are structurally incapable of receiving a slow-down signal — a human clicking submit repeatedly, an API you don't operate pushing data at you on its own schedule — the honest fallback isn't blocking, since there's nothing on the other end able to hear it. It's shedding combined with a generous but still bounded buffer, and, at the point even shedding can't keep up, a circuit breaker at the boundary that refuses admission outright rather than accepting work it already knows it can't finish.
It's also worth being precise that bounded doesn't mean small. A generously sized buffer is often the correct design, not a compromise — it absorbs a genuine, temporary burst that a system should tolerate without immediately pushing back, while still guaranteeing that a sustained mismatch resolves into a visible, deliberate signal instead of an invisible, indefinite pile. Choosing that size is the same kind of tuning problem the earlier piece named for breaker thresholds, with no context-free right answer: too small, and ordinary bursts trigger backpressure that wasn't actually needed; too large, and the backlog still relocates the eventual failure further downstream in time without changing its size — it just takes longer to arrive.
Circuit breakers and backpressure sit at different points on the same underlying question: what does a system do when it cannot handle what's currently being asked of it. A breaker answers that after the fact, at the boundary of a specific dependency call that has already gone bad. Backpressure tries to answer it before the fact, by making the rate mismatch visible and refusable at every hop instead of letting it accumulate somewhere invisible until it isn't. Neither replaces the other. A system with flawless backpressure everywhere still needs breakers, for the failure backpressure was never built to see coming — a dependency that is perfectly capable of accepting load but has simply stopped working correctly. And a system with breakers everywhere but no backpressure will trip them constantly, because it never had a way to avoid arriving at the edge of failure in the first place.