On the other hand, this technique may not be acceptable in the case in which each message is significant. For example, in a payment system, each user's submitted payment must be processed, and it is inadmissible to drop some. Consequently, instead of dropping a message and keeping the bounded queue as the method for handling the pushed data, we may block the producer once the limit has been reached. The queues that are characterized by the ability to block the producer are usually called blocking queues. An example of interaction using a blocking queue with the capacity of three elements is depicted in the following marble diagram:

Unfortunately, this technique negates all of the system's asynchronous behavior. In general, once the producer reaches the queue's limit, it will start being blocked and will be in that state until the consumer has drained an element and free space in the queue became available. We may then conclude that the throughput of the slowest consumer limits the overall throughput of the system. Subsequently, along with negating the asynchronous behavior, that technique also denies the efficient resource utilization. Consequently, none of the cases are acceptable if we want to achieve all three: Resilience, Elasticity, and Responsiveness. 

Moreover, the presence of the queues may complicate the overall design of the system and add an additional responsibility of finding a trade-off between the mentioned solutions, which is another challenge.

In general, an uncontrolled semantic of a pure push model may cause many undesired situations. This is why the Reactive Manifesto mentions the importance of the mechanism that allows systems to gracefully respond to a load, or in other words the need for the mechanism of backpressure control.

Unfortunately, reactive libraries are similar to RxJava 1.x and do not offer such a standardized feature. There is no explicit API that might allow controlling backpressure out of the box.