When a fast producer filter feeds a slower consumer filter through a bounded pipe, what concrete backpressure strategies exist, and what does each one cost?

## What backpressure is Backpressure is the mechanism (or lack of one) that determines what happens at a specific point in a pipeline where an upstream filter is producing data faster than a downstream filter can consume it. It's a problem every real Pipes and Filters system eventually has to face, because filters are independent and nothing in the style guarantees matched throughput between neighboring stages — a filter that does a cheap regex match can trivially outproduce a filter that does a network call or a database write for every record. ## Where the pressure builds Mechanically, the pipe between two filters is some kind of buffer: - an in-memory queue; - an OS pipe's kernel buffer; - a bounded channel in a concurrency library. When the consumer is slower, that buffer starts to fill. What happens next is the entire backpressure design space, and there are really four distinct strategies. | Strategy | What it costs | |---|---| | **Blocking** | a slowdown anywhere downstream propagates all the way upstream | | **Dropping** | correctness — it is the wrong choice anywhere correctness matters, and dropping a row in a financial ETL pipeline or an audit log is a silent data-integrity bug | | **An unbounded buffer** | memory: it converts a throughput problem into a memory problem | | **Explicit demand signaling** | protocol complexity between both filters | ## The four strategies in detail 1. **Blocking.** The first is blocking: once the buffer reaches capacity, the producer's write call blocks until the consumer has drained enough room. This is what a Unix pipe does at the OS level — a process's `write()` to a full pipe simply blocks the writer. It's simple and correctness-preserving (no data is lost, nothing is silently dropped) but it means a slowdown anywhere downstream propagates all the way upstream, potentially to the original data source, which can turn a local slowdown into a global one — e.g. a slow disk write four stages downstream eventually stalls the network read at the very front of the pipeline. 2. **Dropping.** The second strategy is dropping: once the buffer is full, new (or old) data is discarded according to some policy — drop the newest item and keep processing what's buffered, drop the oldest to make room for fresher data, or sample. This bounds both memory and latency, which is exactly why it's the right choice for inherently lossy, sampling-tolerant data like live metrics or a video preview feed, where a late or duplicate frame is worse than a dropped one. It is the wrong choice anywhere correctness matters — dropping a row in a financial ETL pipeline or an audit log is a silent data-integrity bug, often undetected until someone notices numbers don't reconcile weeks later. 3. **An unbounded buffer.** The third 'strategy' is really the absence of one: an unbounded buffer that simply grows to accommodate whatever backlog accumulates. This avoids blocking and avoids dropping data in the short term, which makes it tempting as a quick fix, but it converts a throughput problem into a memory problem, and it fails catastrophically rather than gracefully — the pipeline runs fine until it suddenly doesn't, when the buffer's memory footprint exceeds available heap/RAM and the process is OOM-killed, typically losing everything in the buffer at once, which is often worse than the bounded alternatives it was meant to avoid. 4. **Explicit demand signaling.** The fourth strategy is explicit demand signaling, where the consumer actively tells the producer how much it's currently willing to accept, and the producer respects that signal instead of just pushing until blocked or dropping. TCP's sliding window and the Reactive Streams specification's `request(n)` protocol are concrete implementations of this idea. It gives the most precise control — the producer never sends more than the consumer asked for, so there's no need to block or drop at all in the steady state — but it costs protocol complexity: both filters need to speak the demand-signaling protocol, which is more machinery than a plain read/write pipe and doesn't retrofit easily onto sources that produce data on a schedule they don't control. ## Failure modes in production In production, backpressure failures show up in recognizable patterns. - **An unbounded buffer strategy** shows up as a service that runs fine for hours or days and then dies suddenly under a load spike, with an OOM kill in the logs and no earlier warning signal. - **A blocking strategy without upstream awareness** shows up as request timeouts and cascading latency — a downstream slowdown makes an upstream handler's writes block, which makes that handler miss its own SLA, which can trip a circuit breaker or timeout in a caller several hops further upstream, well outside the pipeline itself. - **A silent-drop strategy** shows up as a data-quality incident — reconciliation reports don't match, or a metrics dashboard shows suspiciously gappy numbers — that's hard to trace back to a full buffer weeks after the drops happened, because nothing crashed or errored at the time. ## A concrete example A concrete real-world example is Apache Kafka Streams, which uses bounded, blocking backpressure by design: a slow consumer causes the framework to pause fetching from the upstream partition rather than buffering unbounded data or dropping records, deliberately trading throughput and latency for the correctness guarantee that no record is silently lost — a choice that makes sense for use cases like event sourcing where data loss is far more costly than added latency.