> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# backpressure
> Flow + feedback: when downstream slows, signal propagates upstream as throttle. Self-regulates the system to the bottleneck rate.
biology computer-science engineering-and-technology human-physical-performance-and-recreation transportation
# Backpressure
## Description
Flow + feedback loop: when downstream processing slows, the slowdown propagates upstream as a signal to throttle. Without backpressure, fast upstream + slow downstream produces buffer overflow, dropped work, or cascading failure; with backpressure, the system self-regulates to the bottleneck rate. One of the most reliably-applicable higher-order concepts across queues, supply chains, traffic merges, and social dynamics.
## Triggers
**User-initiated:** Three recurring trigger patterns:
* **Producer-faster-than-consumer** — user describes a system where producer-rate exceeds consumer-rate ("the LLM calls are queueing faster than they can complete", "we're getting 429s under load") → backpressure as the missing mechanism.
* **Cascading-failure report** — user reports "things falling over" or downstream slowdown propagating upstream as crashes/timeouts rather than throttling → backpressure-absence as the diagnosis.
* **Retry-without-throttle proposal** — user proposes adding retry logic without throttling ("add exponential backoff") → backpressure-as-missing-pair (e.g., "retry backoff is mathematically doomed against a 60s sliding-window quota… continuous-refill Token Bucket beats literal sliding-window array").
**Agent-initiated:** Agent notices a proposed flow-control / retry / rate-limit design that addresses one half of the flow + feedback-loop pair but not the other (retry without throttle, or throttle without backpropagation signal). This often surfaces in an orchestrator-evaluating-worker-output context — the orchestrator catches a worker proposing a partial fix.
**Vocabulary cues:** Because the higher-order concept's name is rarely invoked, retrieval must lean heavily on synonyms — "rate limit," "quota," "throttle," "429," "retry storm," "cascading failure," "fan-out," "concurrency cap," "queue depth," "token bucket," "sliding window," "retry budget," "buffer overflow," "slow downstream," "back off."
**Situation-shape signals:** Any flow with a feedback path candidate. A queue that fills without a way to signal upstream to slow down; a fan-out where the slowest consumer determines aggregate rate; an API quota where retry without throttle creates a retry-storm.
## Exclusions
* **Asynchronous fire-and-forget systems** — no feedback channel, no backpressure possible by construction. Different failure mode: overflow.
* **Hard-real-time systems** — when downstream slowdown isn't acceptable as a signal (must meet deadline), backpressure becomes "we have a problem" rather than "we self-regulate."
## Structure
\= **flow + feedback-loop**. The flow is the moving content (items, work, data, messages); the feedback loop is the upstream signal that downstream can't keep up. Both must be present — flow alone produces overflow; feedback without flow produces no observable behavior.
## Relationships
* [hysteresis](/concepts/hysteresis) — backpressure systems often exhibit hysteresis: once throttled, return to full throughput depends on the path taken, not just current state.
## Examples
Networking gives backpressure its cleanest engineered form. TCP flow control works by having the receiver advertise a *receive window* in every segment — the number of bytes it is currently willing to accept. As the receiving application drains its buffer slowly, the available window shrinks; when it reaches zero, the sender must stop transmitting. The slowdown originates downstream (a busy consumer) and propagates upstream as an explicit signal that throttles the producer, exactly the backpressure shape: flow plus a feedback channel that pushes the constraint back against the direction of data.
The same structure was lifted into application-level stream processing by the Reactive Streams specification, implemented in RxJava as the `Flowable` type. Rather than a push-only model where a fast producer can swamp a slow consumer, Reactive Streams is pull-driven at the demand layer: a subscriber calls `request(n)` to state how many items it can currently handle, and the publisher may emit no more than that until further demand arrives. The consumer's capacity becomes the regulator. Without this signal, the system has no backpressure and fails by overflow — in RxJava, literally a `MissingBackpressureException` or an out-of-memory crash.
**Inference**: backpressure requires a real reverse channel for demand, not just a buffer. A buffer only postpones overrun; the system self-regulates to the bottleneck rate only when the slow consumer can *signal* its rate back to the producer.
In a busy restaurant kitchen, the expediter stands at "the pass" — the handoff point between the cooking line and the dining room — and controls the rate at which new orders are started. When plates begin stacking up at the pass faster than servers can run them out, or when the line is buried under more in-progress tickets than the cooks can finish well, the expediter calls "stop firing" and holds back new tickets instead of announcing them to the line. The signal travels upstream: the cooks stop starting fresh dishes until the backlog clears. The downstream state — how fast finished plates are actually leaving the pass — regulates the upstream rate at which new orders enter production, so quality and timing hold up under a rush rather than the line collapsing into chaos.
**Inference**: The flow is tickets moving from order to finished plate; the feedback is the expediter's hold, which propagates the downstream backlog back to the start of the line as a throttle. Firing every ticket the instant it arrives, with no hold mechanism, is the overflow failure mode — the line gets "weeded," dishes back up, and service quality cascades downward. The expediter self-regulates the kitchen to the rate at which plates can actually be completed and sent out.
The Frank-Starling law of the heart describes how the heart automatically matches its output to the volume of blood returning to it. When venous return rises, more blood fills the ventricle during diastole, stretching the cardiac muscle fibers. That stretch — a physical preload, literally pressure accumulating upstream of the pump's stroke — increases the force of the next contraction, so the ventricle ejects the larger volume rather than letting it back up. The downstream filling state thus regulates the upstream pumping rate through an intrinsic, self-actuating feedback path: no external controller is required, because the stretch *is* the signal.
**Inference**: This is a biological instance of the flow-plus-feedback pair. The flow is blood through the pump; the feedback is the preload-stretch that propagates the downstream filling state back into contraction force. Without it, mismatched right- and left-ventricular outputs would let blood pool until something overflowed; with it, the system continuously self-regulates to the rate set by venous return.
Freeway ramp metering throttles the rate at which cars enter a highway to keep the mainline flowing. The ALINEA control law makes this a true feedback loop: occupancy sensors on the mainline *downstream* of the on-ramp continuously measure how congested the freeway is, and the entrance-ramp meter light adjusts its green interval to drive that measured occupancy toward a target — the critical occupancy at which throughput is maximized. When the downstream lanes begin to fill, the meter slows admissions, holding cars on the ramp rather than dumping them into a jam; when the mainline clears, the meter lets more through. The downstream congestion state regulates the upstream inflow rate, preventing the "capacity drop" where an overloaded merge collapses into stop-and-go and total throughput falls.
**Inference**: A flow-plus-feedback pair in traffic. The flow is vehicles merging onto the freeway; the feedback is the closed-loop occupancy signal that throttles the ramp meter. Letting cars on without the feedback (an open-loop or unmetered ramp) is the cascading-failure case — the merge overwhelms, congestion propagates upstream, and aggregate flow drops below capacity. The metered system self-regulates to the bottleneck rate the mainline can actually absorb.
The "ileal brake" is a feedback mechanism in the digestive tract. When fat that has not yet been absorbed reaches the distal small intestine (the ileum) — a sign that the upstream gut is moving material faster than it can be digested — endocrine cells there release hormones that slow gastric emptying and proximal motility upstream. The arrival of unabsorbed nutrient at the downstream sensor is the signal; throttling the rate at which the stomach delivers new material is the response. This buys the proximal gut more time to absorb, preventing the malabsorption that would result if intake simply outran digestive capacity. (The original 1984 study attributed the effect to enteroglucagon and neurotensin; later work identified peptide YY and GLP-1, co-secreted from ileal L-cells, as the principal mediators.)
**Inference**: A textbook flow-plus-feedback loop in physiology. The flow is chyme moving distally; the feedback is the hormonal signal that downstream cannot keep up, throttling upstream delivery. The system self-regulates to the bottleneck rate — the speed at which nutrients can actually be absorbed — rather than overflowing into the colon undigested.
git workflow: rapid PR merges create upstream backpressure on review queues.
A pressure-relief valve protects process equipment by sensing the very thing it guards against. The valve is held shut by a spring (or pilot pressure) set to a chosen threshold. As long as system pressure stays below that set point the flow path stays closed; the moment pressure climbs above it — because a downstream blockage, a fire, or a runaway reaction has caused fluid to accumulate — the valve lifts and discharges to a flare or safe location, bleeding off mass until pressure drops back below the reseat point. The accumulating pressure state is itself the feedback signal, and venting is the throttle: the device automatically relieves flow exactly when, and only when, the system cannot keep up with what is building inside it. API Standard 520 codifies how such devices are sized so the relieved rate matches the worst-case accumulation rate.
**Inference**: The flow is the process fluid; the feedback is the pressure-actuated lift that responds to the system's own overpressure state. Without it, a blocked or overwhelmed vessel has no way to signal "I cannot accept more" and ruptures — the buffer-overflow failure mode. With it, the system self-regulates at the boundary of safe pressure, the engineering equivalent of throttling upstream when downstream stalls.
The Reactive Streams specification (reactive-streams.org) defines a standard interface for asynchronous stream processing with non-blocking backpressure across the JVM and beyond. Its central contribution is making backpressure a *first-class part of the producer-consumer contract*: subscribers explicitly signal demand to publishers via `request(n)`, and publishers must not emit more elements than have been requested. The spec is implemented by RxJava, Project Reactor, Akka Streams, and the standard `java.util.concurrent.Flow` types in JDK 9+.
**Inference**: This is the engineering canonicalization of the backpressure primitive. Earlier reactive libraries treated backpressure as an afterthought or a runtime concern; Reactive Streams treats it as a structural constraint enforced at the type-system level — the consumer can never be overwhelmed because it controls how much it has asked for.