Backpressure is a mechanism that allows a downstream component to signal an upstream component to slow down — preventing fast producers from overwhelming slow consumers. Without backpressure, intermediate buffers grow without bound until memory is exhausted, causing out-of-memory crashes or massive latency spikes. Effective backpressure design is foundational to building reliable data pipelines, streaming systems, and any producer-consumer architecture.
Why Unbounded Queues Fail
An unbounded queue between a fast producer and a slow consumer appears to solve the speed mismatch: the producer enqueues items at its rate; the consumer dequeues at its rate. But if the producer is persistently faster than the consumer, the queue grows without limit. At 10MB/s production rate and 8MB/s consumption rate, the queue grows 2MB/s. After 10 minutes, 1.2GB is queued. The system eventually runs out of memory, dies, and loses all queued data. Bounded queues force the producer to deal with back-pressure explicitly.
Backpressure Strategies
Block the Producer
When the queue is full, block the producing thread until space is available. Go channels with fixed capacity implement this naturally: sending to a full channel blocks until a receiver reads an item. This propagates pressure upstream — the slow consumer slows the producer, which slows whatever is feeding the producer. Simple and correct for in-process pipelines. Problematic when blocking the producer also blocks I/O or holds locks that cause deadlock.
Drop with Policy
When the buffer is full, drop incoming items according to a policy: drop the newest (fail-fast: tell the producer to retry later), drop the oldest (sliding window: keep the most recent data, lose old data), or drop randomly (probabilistic shedding). Dropping is appropriate when data has bounded utility — a metrics sample from 5 minutes ago is less valuable than the current one, so dropping old metrics under load is acceptable. Never drop without emitting a counter — track drops as a critical metric.
Reactive Pull Model
Instead of the producer pushing data to the consumer, the consumer pulls: “I am ready for N more items, send them.” The producer sends exactly N items and waits for the next pull request. This is the Reactive Streams protocol (used by Akka Streams, Project Reactor, RxJava). The consumer controls the flow rate entirely — it requests more only when it has capacity to process them. Kafka consumers implement this: the consumer polls for a batch of messages, processes them, commits offsets, then polls again. The producer (Kafka broker) only delivers what is requested.
TCP Flow Control
TCP’s receive window implements backpressure at the network level. The receiver advertises how many bytes its buffer can accept (the receive window). The sender limits in-flight data to the window size. When the receiver’s buffer fills (slow application layer), the window shrinks to zero — the sender stops transmitting. When the application reads from the buffer, the window expands. This mechanism propagates backpressure from a slow application all the way back to the remote sender without any application-level protocol changes.
Backpressure in Stream Processing
Apache Flink implements end-to-end backpressure: if a downstream operator is slow, it stops reading from its input buffers. This fills the upstream operator’s output buffer. The upstream operator blocks when its output buffer is full, which fills its own input buffer, which propagates back to the source. The entire pipeline slows to the rate of the slowest stage — no data is lost, no buffers overflow. Monitor backpressure ratios in Flink’s metrics: a stage with 100% backpressure is the bottleneck; optimize it or add parallelism.
Design Checklist
For any producer-consumer system: (1) use bounded buffers — never unbounded queues in production; (2) decide the backpressure strategy (block, drop, pull) based on the data’s value and latency requirements; (3) emit metrics for queue depth and drop rate — monitor them; (4) test under sustained overload — run a load test where the producer rate exceeds consumer capacity for 10 minutes and verify the system stabilizes rather than crashing; (5) propagate backpressure through the entire chain — a bottleneck in stage 3 should slow stage 1, not fill stage 2’s buffer.
See also: Meta Interview Guide 2026: Facebook, Instagram, WhatsApp Engineering
See also: Uber Interview Guide 2026: Dispatch Systems, Geospatial Algorithms, and Marketplace Engineering
See also: Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering
See also: Airbnb Interview Guide 2026: Search Systems, Trust and Safety, and Full-Stack Engineering
See also: Databricks Interview Guide 2026: Spark Internals, Delta Lake, and Lakehouse Architecture
See also: Anthropic Interview Guide 2026: Process, Questions, and AI Safety
See also: Atlassian Interview Guide
See also: Coinbase Interview Guide
See also: Shopify Interview Guide
See also: Snap Interview Guide
See also: Lyft Interview Guide 2026: Rideshare Engineering, Real-Time Dispatch, and Safety Systems
See also: Stripe Interview Guide 2026: Process, Bug Bash Round, and Payment Systems