Skip to content

Backpressure

1. What is it? (2-3 lines)

Backpressure is a flow-control feedback mechanism in data processing pipelines where a downstream consumer signals an upstream producer to slow down or pause message transmission when incoming traffic exceeds consumer processing capacity.

2. Why does it exist?

In push-based streaming systems or asynchronous pipelines, if Producer rate (\(100,000\text{ msgs/sec}\)) exceeds Consumer processing capacity (\(10,000\text{ msgs/sec}\)), internal memory buffers explode, resulting in Out-Of-Memory (OOM) crashes, lost messages, or runaway latency. Backpressure propagates resistance backward up the pipeline to keep system resource usage stable.

3. Where is it used?

  • Stream Processing Frameworks: Reactive Streams (RxJava / Project Reactor request(n)), Apache Flink, Akka Streams.
  • Message Streaming Brokers: Apache Kafka (Pull-based natural backpressure), Reactive gRPC / HTTP/2 flow control.
  • Database & I/O Pipelines: Node.js streams (stream.write() == false), TCP Window Sizing.

4. How does it work? (simple flow)

  • Reactive Streams Pull-Based Credit Flow (request(n)):
  • Consumer sends credit signal to Producer: "Send me 10 messages (request(10))."
  • Producer emits 10 messages and stops.
  • Consumer processes 10 messages \(\to\) Sends new credit signal request(10).
  • TCP Window Sizing (Network Backpressure):
  • Receiver OS TCP buffer fills up \(\to\) Shrinks TCP Window Size header to 0 in ACK packet.
  • Sender OS TCP stack pauses transmitting data packets until Receiver advertises a non-zero Window Size.
  • Kafka Pull Architecture (Natural Backpressure):
  • Consumers execute poll() requests when ready.
  • If consumer slows down, it delays its next poll() call \(\to\) Messages buffer safely on broker disk logs without crashing consumer RAM!

5. Decision Matrix

Mechanism Strategy Behavior Under Overload Memory Risk
Pull-Based Credit (request(n)) Flow Control Producer slows down to match consumer speed Zero (Zero un-requested memory buildup)
Buffer & Log (Kafka) Storage Buffering Messages buffer on disk log; consumer lags Low (Buffered on broker disk, not consumer RAM)
Drop / Load Shedding Rejection Drops newest (Drop Head) or oldest (Drop Tail) items Low (Discards data to protect RAM)
Block / Wait Synchronous Blocking Sender thread blocks waiting for queue space High (Risk of thread pool deadlock)

6. Limitations

  • Cascading Slowdown: Backpressure propagates all the way back to edge producers, potentially rejecting incoming user HTTP API requests (429 / 503).
  • Buffering at producer layers increases end-to-end processing latency.

7. Common interview questions (10)

  1. What is Backpressure and why is it essential in reactive stream processing?
  2. How does Apache Kafka's Pull-based architecture provide natural Backpressure compared to push-based brokers?
  3. How does TCP Sliding Window Flow Control enforce network-level Backpressure?
  4. How do Reactive Streams specifications (request(n) in RxJava/Reactor) implement credit-based flow control?
  5. What are the 4 standard Backpressure strategies when buffers fill up (Block, Drop Latest, Drop Oldest, Error)?
  6. How does Apache Flink implement Credit-Based Flow Control between TaskManager network channels?
  7. What is the difference between Rate Limiting and Backpressure?
  8. How does Node.js handle Backpressure in stream pipes (readable.pipe(writable))?
  9. How does HTTP/2 Flow Control (WINDOW_UPDATE frames) prevent stream buffer overflow?
  10. What happens when Backpressure propagates all the way back to an API Gateway entry point?

8. Common misconceptions

  • Misconception: Backpressure increases processing speed. Fact: Backpressure intentionally slows down producers to match consumer processing capacity, prioritizing system stability over raw input speed.
  • Misconception: Infinite memory queues solve fast producer problems. Fact: Infinite queues simply delay the problem until the application crashes with a fatal OutOfMemoryError.

10. 30-second cheat sheet

  • Definition: Downstream consumer tells upstream producer to slow down to match processing capacity.
  • Kafka Solution: Pull-based model (poll()) \(\implies\) Consumer requests data ONLY when ready. Messages buffer on disk.
  • Reactive Stream Solution: Credit-based request(n) protocol.
  • Overload Strategies: Block (Wait), Drop Latest (Shed), Drop Oldest, or Error (429/503).
  • Golden Rule: NEVER use unbounded in-memory queues! Always enforce flow control or bounded queues.