Sweaty Imposter

Backpressure

TechniqueThroughput and FlowMidSeniorUpdated
When a downstream component is slow, signal upstream to slow down (don't just buffer and OOM).

When to Use Backpressure

Anywhere a producer can outrun a consumer: streams, queues, network sockets, UI event loops. Without backpressure, slowness becomes outages.

In Practice

Node.js streams expose .write() returning false; Reactive Streams (RxJava, Project Reactor) make backpressure first-class via request(n). Kafka consumers use offset commits as natural backpressure.

How Backpressure Comes Up in Interviews

Scenario

A Kafka consumer's processing is slower than producer throughput. Memory is climbing because messages are queuing up in the consumer process. What general technique is missing?

Backpressure signals upstream to slow down when the consumer can't keep up (e.g., via offset-commit-paced fetches) instead of buffering until OOM. Throttling caps a rate but doesn't propagate consumer slowness back to the producer.

Backpressure is the discipline of propagating downstream slowness upstream so producers slow down instead of producers pumping data into an ever-growing buffer until the consumer OOMs. Kafka's natural backpressure is offset commits, the consumer's lag is visible to monitoring and operators can scale up consumers or slow down producers in response. Node.js streams expose .write() returning false to signal 'I'm full, wait for drain.' Reactive Streams (RxJava, Project Reactor) make backpressure first-class via request(n). Throttling caps a rate at a fixed value but doesn't react to consumer health; backpressure is dynamic.

Where It Comes Up