Reactive applications use backpressure to manage of Stream of data flow from publishers to subscribers. It can be either a pull or push backpressure model depending on the requirements of the event. The pull data retrieval model is the one controlled by the subscriber which might be causing degradation or starvation whenever an empty promise Stream object is emitted by the publisher. A similar scenario is exhibited by the testByRequest() test case where the subscriber used the request() method of Subscription to tell the publisher how many Stream objects to emit per batch. On the other hand, we have a push model where the publisher controls the emission using some threaded operators such as timeout(), delayElements(), buffer(), skip(), and take(). This method promotes resiliency which means that the publisher will not be causing too much stress on its subscribers by sending an overflowing or empty stream. Given the possible chances of an empty stream, the push model can manage Throwable or execute Mono.error() to avoid memory leaks.

There are cases where some operations exceed the given time of execution due to I/O transactions, network problems, or huge volumes of data. Stream operators that are affected by these circumstances are wrapped by a defer() asynchronous method to prevent others from interfering with the ongoing status of the deferred operation. Using this method is a good start in formulating asynchronous transactions with backpressure for events that consume too many resources. Given different subscribers, the defer() method ensures a new Stream for each subscriber.

Some of the delay operations are deprecated so it would be wise to use the updated Reactor Core 3.0 operators. Moreover, for the time-driven operators, onCancel() is always triggered and doOnCancel() can be invoked for further Runnable tasks or events.