What is Backpressure in Distributed Systems?
Learn what backpressure is, how TCP and reactive streams implement it, and fallback strategies like load shedding for overload.
Expected Interview Answer
Backpressure is a flow-control mechanism where a slower downstream consumer signals an upstream producer to slow down or pause sending data, preventing the consumer from being overwhelmed and its buffers from growing unbounded until the system runs out of memory or crashes.
Without backpressure, if a producer generates data faster than a consumer can process it, the excess must go somewhere — typically an in-memory queue — and that queue grows without bound until it exhausts memory, causing latency spikes or an outright crash. Backpressure mechanisms make this pressure explicit and propagate it upstream: TCP itself implements backpressure via its receive window, pausing the sender when the receiver’s buffer fills; reactive streams (RxJS, Project Reactor) let a subscriber request only as many items as it can currently handle; and message queues expose consumer lag or apply credit-based flow control so producers throttle themselves. The alternative strategies when backpressure cannot be propagated are load shedding (drop excess requests), buffering with a bounded and monitored queue, or backpressure-aware batching, but simply ignoring the problem and letting queues grow unbounded is what causes cascading outages in production.
- Prevents unbounded queue growth and out-of-memory crashes under load
- Keeps end-to-end latency predictable instead of degrading as queues balloon
- Makes capacity mismatches between producer and consumer visible instead of silently buffered
- Allows graceful degradation via explicit strategies like load shedding when propagation is not possible
AI Mentor Explanation
Backpressure is like a bowler who must wait for the umpire to signal “ready” before running in for the next delivery, instead of bowling as fast as physically possible regardless of whether the fielding side has reset. If the fielders (the consumer) are still retrieving the ball from the boundary, the umpire holds up play, and the bowler slows down rather than firing balls that no one can field. Without that signal, deliveries would pile up faster than the fielding side could ever process them, and the game would descend into chaos. That explicit “wait for readiness” signal from the slower side back to the faster side is exactly backpressure.
Step-by-Step Explanation
Step 1
Consumer falls behind producer
The downstream consumer processes data slower than the upstream producer generates it.
Step 2
Buffer begins to grow
Excess data accumulates in an in-memory queue or buffer between producer and consumer.
Step 3
Consumer signals upstream to slow down
Via a mechanism like TCP’s receive window, reactive stream demand signaling, or consumer lag metrics, the consumer explicitly communicates it needs less data.
Step 4
Producer throttles or an alternate strategy kicks in
The producer slows its output rate to match; if propagation is impossible, the system falls back to load shedding or bounded, monitored buffering.
What Interviewer Expects
- Defines backpressure as an explicit signal from consumer back to producer, not just “the system is slow”
- Names at least one concrete mechanism: TCP receive window, reactive streams demand, consumer lag / credit-based flow control
- Explains the failure mode without backpressure: unbounded queue growth leading to OOM or latency collapse
- Mentions fallback strategies when backpressure cannot be propagated: load shedding, bounded queues
Common Mistakes
- Conflating backpressure with simply “adding more buffer” (buffering alone does not solve unbounded growth)
- Not naming any concrete implementation mechanism
- Assuming backpressure is only relevant to streaming libraries, missing that TCP itself does this
- Forgetting that when backpressure cannot propagate end-to-end, load shedding is a legitimate fallback, not a failure
Best Answer (HR Friendly)
“Backpressure is a way for a system to tell a faster upstream sender to slow down when the receiver cannot keep up, instead of letting unprocessed work pile up endlessly until something crashes. It is like a receiver saying “wait, I am not ready for more yet,” and it is a core part of building systems that stay stable even when load spikes unexpectedly.”
Code Example
class BackpressuredQueue {
constructor(maxSize) {
this.maxSize = maxSize
this.items = []
this.waitingProducers = []
}
async push(item) {
if (this.items.length >= this.maxSize) {
// Signal backpressure: producer must wait until there is room
await new Promise((resolve) => this.waitingProducers.push(resolve))
}
this.items.push(item)
}
pop() {
const item = this.items.shift()
// Consumer freed a slot; wake one waiting producer
const nextProducer = this.waitingProducers.shift()
if (nextProducer) nextProducer()
return item
}
}
// Producer awaits push(), so it naturally slows down
// whenever the consumer falls behind and the queue fills up.Follow-up Questions
- How does TCP implement backpressure at the transport layer?
- What is the difference between backpressure and simply increasing buffer size?
- When backpressure cannot be propagated end-to-end, what fallback strategies exist?
- How do reactive streams (like RxJS or Project Reactor) implement demand-based backpressure?
MCQ Practice
1. What problem does backpressure primarily prevent?
Backpressure explicitly signals a producer to slow down so a slower consumer is not overwhelmed by unbounded buffering.
2. Which of these is a real-world example of backpressure in action?
TCP implements backpressure at the transport layer via its receive window, throttling the sender based on receiver capacity.
3. When backpressure cannot be propagated all the way to the original producer, what is a common fallback strategy?
Load shedding lets a system stay stable by dropping excess load deliberately, rather than letting queues grow unbounded.
Flash Cards
What is backpressure? — A flow-control signal where a slower consumer tells a faster producer to slow down, preventing unbounded buffer growth.
TCP backpressure mechanism? — The receive window, which pauses the sender when the receiver’s buffer is full.
Failure mode without backpressure? — Queues grow unbounded, leading to out-of-memory crashes or latency collapse.
Fallback when backpressure cannot propagate? — Load shedding — deliberately dropping excess requests to protect system stability.