# Backpressure Backpressure is a feedback mechanism: a component that receives more work than it can process tells the components upstream to slow down. The Reactive Manifesto puts it this way: a component under stress can't cope and can't fail, so it "should communicate the fact that it is under stress to upstream components and so get them to reduce the load". ## Why it matters When a fast producer feeds a slow consumer and nothing pushes back, there are three outcomes. The queue between them grows until memory runs out, the consumer drops work in an uncontrolled way, or it crashes. Even before the crash, a growing queue means a growing wait: by [[Little's Law]], at constant throughput, more items in the system means each item spends longer in it. Backpressure turns that hidden pile-up into a signal the producer can act on (slow down, [[Load Shedding|shed load]], add capacity). The pressure may travel all the way up to the user, who sees a slower response, but the system stays up instead of collapsing. That's also why it's one of the defenses against [[Cascading Failures]]. ## How it works in practice - **[[TCP IP|TCP]] flow control and Unix pipes** are the classic examples: a full receive buffer or pipe makes the sender wait - **[[Node.js]] streams**: `writable.write()` returns `false` once the buffer passes its `highWaterMark`; the readable side pauses until the writable emits `drain` - **Reactive Streams**, a standard for asynchronous stream processing with non-blocking backpressure on the JVM and in JavaScript: the subscriber requests a number of elements and the publisher never sends more than requested. Java 9 adopted the same interfaces as `java.util.concurrent.Flow` - **Services**: bounded queues, and rejecting work (e.g., HTTP 503) when they're full instead of accepting everything. [[Michael Nygard]] lists "Create Back Pressure" among the stability patterns in [[Release It! (Book)|Release It!]] ## Limits Backpressure only helps when the producer can actually slow down. User clicks, sensor readings and market data keep arriving whatever the consumer says. In those cases you're back to bounded buffers, sampling or load shedding. Across service boundaries, it also depends on callers respecting the signal: a client that answers a rejection with immediate [[Retry pattern|retries]] adds load instead of removing it. ## References - The Reactive Manifesto, glossary entry "Back-Pressure": https://www.reactivemanifesto.org/glossary#Back-Pressure - Reactive Streams: https://www.reactive-streams.org/ - Node.js, "Backpressuring in Streams": https://nodejs.org/en/learn/modules/backpressuring-in-streams - Michael Nygard, Release It! Second Edition, Pragmatic Bookshelf, 2018 (Stability Patterns chapter): https://pragprog.com/titles/mnee2/release-it-second-edition/ - Google SRE book, "Addressing Cascading Failures" (load shedding and queue management): https://sre.google/sre-book/addressing-cascading-failures/ - https://concepts.dsebastien.net/concept/backpressure/ ## Related - [[Cascading Failures]] - [[Circuit Breaker]] - [[Little's Law]] - [[Feedback Loop]] - [[Node.js]] - [[Bun]] - [[Cloudflare Pipelines]] - [[Release It! (Book)]] - [[Michael Nygard]] - [[Load Shedding]] - [[Exponential Backoff]] - [[TCP IP]] - [[Rate Limiting]] - [[Retry pattern]]