Backpressure in Reactive Systems
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.
Join the DZone community and get the full member experience.Join For Free
Mid-January, I held a talk at Kotlin.amsterdam based on my post Migrating from Imperative to Reactive (a Spring Boot application). Because it was a Kotlin meetup, I demoed Kotlin code, and I added a step by migrating the codebase to coroutines. During Q&A, somebody asked whether coroutines implemented backpressure. I admit I was not sure of the answer, so I did a bit of research.
What Is Backpressure?
Back pressure (or backpressure) is a resistance or force opposing the desired flow of fluid through pipes, leading to friction loss and pressure drop.
The term back pressure is a misnomer, as pressure is a scalar quantity, so it has a magnitude but no direction.
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
Here's the class diagram:
Subscription is at the root of backpressure via its
The specifications are pretty straightforward:
SubscriberMUST signal demand via
Subscription.request(long n)to receive
The intent of this rule is to establish that it is the responsibility of the Subscriber to decide when and how many elements it is able and willing to receive. To avoid signal reordering caused by reentrant Subscription methods, it is strongly RECOMMENDED for synchronous Subscriber implementations to invoke Subscription methods at the very end of any signal processing. It is RECOMMENDED that Subscribers request the upper limit of what they are able to process, as requesting only one element at a time results in an inherently inefficient "stop-and-wait" protocol.
Reactive Streams' specifications are pretty solid. They also come with a Java-based TCK (Test Compatibility Kit).
But it falls outside the specifications' scope to define how to manage items emitted by the producer that cannot be handled downstream. While the problem is pretty simple, different solutions are possible. Each Reactive framework provides some options, so let's see them in turn.
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:
||A flow with either:
||A flow with no item but either:
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 underconsuming Subscriber go away. It just moves the problem up the chain of operators to a point where it can be handled better.
To cope with that, RxJava offers two main strategies to handle 'overproduced' items:
Store items in a buffer:
Note that if you set no upper bound to the buffer, it might cause
The following diagram summarizes the different methods that implement those strategies:
Note that the
onBackPressureLatest operator is similar to using
Note that I took the above Marble diagrams from RxJava's wiki.
Compared to other frameworks, RxJava offers methods to send an overflow exception signal after sending all items. These allow the consumer to receive items and still be notified that the producer has dropped items.
Backpressure in Project Reactor
Strategies offered by Project Reactor are similar to those of RxJava's.
The APIs have some slight differences, though. For example, Project Reactor offers a convenient method to throw an exception if the producer overflows:
- Create the Reactive Stream.
- Throw if the producer overflows
Flux class diagram that highlights backpressure capabilities:
Compared to other frameworks, Project Reactor offers methods to set a TTL for buffered items to prevent overflowing it.
Backpressure in Coroutines
Coroutines do offer the same buffering and dropping capabilities. The base class in coroutines is
You can use the classes like this:
- Create a
Flowwhich content is defined by the next block.
- Define the
- Set the buffer's capacity to 10.
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.
Thanks to my friend Oleh Dokuka for his kind review.
To Go Further:
- Reactive Streams JVM specifications
- How (not) to use Reactive Streams in Java 9+
- RxJava Backpressure
Originally published at A Java Geek on March 14th 2021.
Published at DZone with permission of Nicolas Fränkel, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.