In software, backpressure has a slightly related but still different meaning: considering a fast data producer and a slow data consumer, backpressure is the mechanism that “pushes back” on the producer not to be overwhelmed by data.
Whether based on reactivestreams.org or Java’s
java.util.concurrent.Flow, Reactive Streams provides four building blocks
Publisherthat emits elements
Subscriberthat reacts when elements are received
Subscriptionthat binds a
- And a
Due to the non-blocking nature of Reactive Programming, the server doesn’t send the complete stream at once. It can push the data concurrently as soon as it is available. Thus, the client waits less time to receive and process the events. But, there are issues to overcome.
Backpressure in software systems is the capability to overload the traffic communication. In other words, emitters of information overwhelm consumers with data they are not able to process.
Eventually, people also apply this term as the mechanism to control and handle it. It is the protective actions taken by systems to control downstream forces.
Backpressure in RxJava 3
RxJava v3 provides several base classes:
|A flow of 0..N items. It supports Reactive-Streams and backpressure.|
|A flow of 0..N items. It doesn’t support backpressure.|
|A flow of exactly:1 itemor an error|
|A flow with either:no itemsexactly one itemor an error|
|A flow with no item but:either a completionor an error signal|
Among these classes,
Flowable is the only class that implements Reactive Streams – and backpressure. Yet, providing backpressure is not the only issue. As RxJava’s wiki states:
Backpressure doesn’t make the problem of an overproducing Observable or an under consuming Subscriber go away. It just moves the problem up the chain of operators to a point where it can be handled better here.
All in all, RxJava, Project Reactor, and Kotlin coroutines all provide backpressure capabilities. All cope with a producer that is faster than its subscriber by offering two strategies: either buffer items or drop them.