RxJava Basics with example | Backpressure – DROP, ERROR, LATEST, MISSING, BUFFER | Good for beginners

In this article we will go through very basic & simple examples of backpressure handling in RxJava 2. For synchronous, async & parallel processing refer this article.

RxJava Basics with example | Create, Subscribe, Synchronous, Async, Parallel, Backpressure, Non-Blocking | Good for beginners


During asynchronous processing, if subscriber is consuming data slower than publisher, this situation is called as backpressure. RxJava provides ways to handle the Backpressure gracefully.

Observable – In case of Observable, there is unbounded buffer i.e. infinite buffer. So all the data published/emitted is stored in memory & made sure that subscriber receives that. But if published data is very very huge, then it might cause OutOfMemory error eventually. Observable does not provide graceful ways to handle this backpressure.

Flowable – Flowable provides graceful ways to handle backpressure. In next section, we will look at different strategies offered by Flowable. Flowable also has default buffer of 128 values.

Backpressure Strategy: DROP

DROP strategy drops the most recent onNext value if the downstream can’t keep up because its too slow. There are also ways provided to consume dropped values and handle them separately.

In below output you can see that till 128 (default buffer size), values were successfully published & then values starts dropping. Subscriber also received 128 values successfully.

Backpressure Strategy: LATEST

LATEST strategy keeps only the latest onNext value, overwriting any previous value if the downstream can’t keep up because its too slow.

In below output you can see that publishing of all 999 values seems to have gone fine. Subscriber also started asynchronously receiving values. But you can see subscriber directly received 923 after 127. This means that after 127 (default buffer of 128), all values were replaced with latest & finally last values of 923 & above remained in buffer & received by subscriber.

Backpressure Strategy: ERROR

ERROR strategy throws MissingBackpressureException in case the downstream can’t keep up due to slowness. Publisher can handle exception & make sure to call onError handle so that subscriber can do handling on subscriber side for such error scenarios.

You can see in below output that publishing & subscribing started on different threads. Subscriber received values till 314 & then onError handler was called due to MissingBackpressureException. After that subscriber stopped.

Backpressure Strategy: MISSING

With MISSING strategy, as name suggests there is no buffering or dropping. Subscriber must handle overflow else they will receive error.

Backpressure Strategy: BUFFER

With BUFFER strategy, as name suggests all values are buffered so that subscriber can receive all values. As per program below, buffer is infinite, so if published values are large in count & subscriber is too slow, then there is chance of out of memory just like Observable.


Leave a Reply

Your email address will not be published. Required fields are marked *