Reactive Streams
A specification for asynchronous stream processing in which the consumer requests a specific number of items, making backpressure part of the protocol rather than an afterthought.
The inversion at its centre: in a push model the producer decides the rate and the consumer copes; in
Reactive Streams the consumer signals demand (request(n)) and the producer may only emit that
many. Backpressure is therefore not something you add — it is the only way data moves.
The interfaces are deliberately tiny — Publisher, Subscriber, Subscription, Processor — and the
specification is mostly a set of rules about what implementations must guarantee. It underlies
Project Reactor, RxJava and Akka Streams, and was absorbed into the JDK as java.util.concurrent.Flow.
Where it earns its place: a pipeline whose stages have different throughput, and where the slow stage must be able to slow the fast one without an unbounded buffer between them. A file reader feeding a slow HTTP client is the canonical case.
Where it does not help: across a network boundary that does not itself implement flow control. The demand signal has to traverse the same path, which is why HTTP/2 flow control and gRPC streaming matter — the transport must participate or the backpressure stops at the socket buffer.