Even though the Reactive Stream specification requires backpressure to be built into the communication between the producer and consumer, it is still possible to overflow the consumer. Some consumers may innocently request an unbound demand and then fail to handle the generated load. Some consumers may have hard limitations for the rate of incoming messages. For example, a database client may not insert more than 1,000 records per second. In that case, events batching techniques may help. We covered that approach in the Batching stream elements section. Alternatively, we can configure a stream to handle backpressure situations in the following ways:

• The onBackPressureBuffer operator requests an unbounded demand and pushes returned elements to a downstream. However, if a downstream consumer cannot keep up, elements are buffered in a queue. The onBackPressureBuffer operator has many overrides and exposes many configuration options, which facilitate the tuning of its behavior.
• The onBackPressureDrop operator also requests an unbounded demand (Integer.MAX_VALUE) and pushes data downstream. If not enough demand is requested from downstream, elements are dropped. It is possible to handle dropped elements with a custom handler.
• The onBackPressureLast operator works similarly to onBackPressureDrop. However, it remembers the most recently received element and pushes it downstream as soon as the demand appears. It may help to always receive recent data, even in overflow situations.
• The onBackPressureError operator requests an unbounded demand while trying to push data downstream. If a downstream consumer cannot keep up, the operator raises an error.

Another way of managing backpressure may be through the rate-limiting technique. The limitRate(n) operator splits the downstream demand into smaller batches not bigger than n. In this way, we may protect our delicate producer from an unjustified data request from a downstream consumer. The limitRequest(n) operator allows the limiting of the demand (the total requested values) from a downstream consumer. For example,  limitRequest(100) makes sure that a producer will not be requested for more than 100 elements in total. After sending 100 events, the operator successfully closes the stream.