Rx leads events from end of a pipeline to the other end. The actions that take place on each end can be very dissimilar. What happens when the producer and the consumer require different amounts of time to process a value? In a synchronous model this question isn't an issue. Consider the following example:

Observable<Integer> producer = Observable.create(o -> {

o.onNext(1);

o.onNext(2);

o.onCompleted();

});

producer.subscribe(i -> {

try {

Thread.sleep(1000);

System.out.println(i);

} catch (Exception e) { }

});

Here, the producer has its values ready and can emit them with no delay. The consumer is very slow by comparison. But this isn't going to cause problems, because the synchronous nature of the code above automatically regulates the rates of the producer and consumer. When `o.onNext(1);` is called, execution for the producer is blocked until the entire Rx chain completes. Only when that expression returns can the execution proceed to `o.onNext(2);`.

But this is only for synchronous execution. It is very common for the producer and the consumer to be asynchronous and we've already seen Rx's elegant way of handling and introducing asynchronicity. So, what happens when a producer and a consumer operate asynchronously at different speeds?

Let's first consider a pull-based model, such as an iterator. In a pull-based model, the consumer requests the values. If the producer is slower, the consumer will block on request and resume when the next value arrives. If the procuder is faster, then it will have idle time waiting for the consumer request the next value.

Rx push-based, not pull-based. In Rx it is the producer that pushes values to the consumer when the values are ready. If the producer is slower, then the consumer will have idle time waiting for the next value to arrive. If producer is faster, without any provisions, it will keep force-feeding data to consumer without ever knowing about the consumer's difficulties.

Some of the operators we've seen in previous chapters can help the consumer lessen the stress caused by too much input.

The [sample](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#sample) operator allows you to specify a maximum rate of input, while the rest will be ignored.

There other similar operators that will thin out your data, such as [throttle](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#throttling) and [debounce](/Part 3 - Taming the sequence/5. Time-shifted sequences.md#debouncing).

You can also use `buffer` and `window` to collect overflowing data while the consumer is busy. Then you can decide manually how many and which of the buffered items are worth processing.

The above remedies are legitimate solutions to the problem. However, they aren't always the best way to deal with an overproducing observable. Sometimes the problem can be better handled on the side of the producer. We call the process of resisting emissions by an observable _backpressure_.

RxJava has implemented a way for a subscriber to regulate the rate of an observable. The `Subscriber` has a `request(n)` method, with which it notifies the observable that it is ready to accept `n` more values. By calling `request` on the `onStart` method of your `Subscriber` you establish reactive pull backpressure. This isn't a pull: it doesn't return any values and will not block if values are not ready. Instead, it merely notifies the observable of how many values the `Subscriber` is ready to accept and to hold the rest. Subsequent calls to `request` will allow more values through.

This is a `Subscriber` that takes values one at a time:

class MySubscriber extends Subscriber<T> {

@Override

public void onStart() {

request(1);

}

@Override

public void onCompleted() {

...

}

@Override

public void onError(Throwable e) {

...

}

@Override

public void onNext(T n) {

...

request(1);

}

}

The `request(1)` in `onStart` establishes backpressure and that the observable should only emit the first value. After processing in `onNext`, we request the next item to be sent, if and when it is available. Calling `request(Long.MAX_VALUE)` disables backpressure.

Many Rx operators use backpressure internally to avoid overfilling their internal queues. That way, the problem is propagated backwards into the chain of operators. Backpressure doesn't make the problem go away. It merely moves it where it may be handled better. An overproducing observable can still overwhelm the internal buffers of operators.

There are Rx operators that declare how you want to deal with situations where values are not consumed fast enough.

The `onBackpressureBuffer` operator with cause every value that can't be consumed to stored until the observer can consume it.

You can have a buffer of infinite size of a buffer with a maximum capacity. If the buffer overflows, it will fail with a `BufferOverflowException`.

The `onBackpressureDrop` operator discards items that are not ready to be received.