Learn the vocabulary of a slow consumer signaling upstream to prevent being overwhelmed.
0 / 5 completed
1 / 5
At standup, a dev mentions a slow consumer signaling upstream that it can't keep up, so the producer slows down or buffers instead of overwhelming the consumer with data it can't process in time. What is this mechanism called?
Backpressure is a mechanism where a slow consumer signals upstream that it can't keep up, letting the producer slow down or buffer data instead of overwhelming the consumer with more than it can process in time. A producer sending data at a fixed rate with no awareness of the consumer's actual capacity risks the consumer's internal queue growing unboundedly until it runs out of memory or crashes. This feedback mechanism is essential for keeping a streaming or message-passing system stable under real, variable load.
2 / 5
During a design review, the team wants the system to explicitly bound how much unprocessed data a consumer's internal queue can hold, rejecting or pausing new input once that bound is reached. Which capability supports this?
A bounded queue with an explicit capacity limit rejects or pauses new incoming input once that limit is reached, preventing a consumer's internal backlog from growing without limit when it can't keep pace with the producer. An unbounded queue accepting unlimited unprocessed data defers the resource problem rather than solving it, eventually exhausting available memory during a sustained mismatch between producer and consumer speed. This explicit bound is what actually gives the system a concrete signal to trigger backpressure in the first place.
3 / 5
In a code review, a dev notices a reactive streaming library's consumer explicitly requests a specific number of items it's ready to process next, rather than the producer pushing an unlimited stream regardless of consumer readiness. What does this represent?
A pull-based, demand-driven backpressure protocol has the consumer explicitly request a specific number of items it's currently ready to process, rather than the producer pushing an unlimited stream regardless of whether the consumer can actually keep up. A purely push-based producer risks overwhelming a consumer that temporarily slows down for any reason. This demand-driven pattern, used by reactive streaming libraries, gives the consumer direct, fine-grained control over its own incoming data rate.
4 / 5
An incident report shows a producer kept sending data at a fixed high rate despite a downstream consumer signaling it was falling behind, since the producer had no mechanism to actually respond to that signal. What practice would prevent this?
Implementing an actual backpressure-responsive mechanism lets a producer genuinely slow down or buffer when a consumer signals it's falling behind, rather than the consumer's signal being detected but having no real effect. A producer that ignores that signal defeats the entire purpose of backpressure, continuing to overwhelm a consumer that already indicated it can't keep up. This end-to-end responsiveness, not just detecting the mismatch but actually reacting to it, is what makes backpressure meaningfully protective.
5 / 5
During a PR review, a teammate asks why the team implements backpressure instead of just letting the producer send data as fast as possible and relying on the consumer to keep up. What is the reasoning?
Without backpressure, a temporarily slow consumer, perhaps due to a garbage collection pause or a downstream dependency slowing down, has its internal queue grow unboundedly as the producer keeps sending data regardless. Backpressure gives the consumer a way to signal that mismatch, letting the producer slow down or buffer to keep the whole system stable. The tradeoff is the added protocol complexity of implementing and correctly responding to this upstream signaling.