Reactive Streams is described simply as an initiative to provide a standard for asynchronous stream processing with non-blocking backpressure. It is a small and straightforward statement. However, it is essential to note that the first focus here is on the asynchronous stream processing and not just on the asynchronous programming. As discussed earlier, asynchronous systems have been around for a long time.

Before processing a stream, comes receiving the stream data. Asynchronously, this would mean managing the risk of uncertainties in the world of streams. For example, how much more data or messages could there be? Another challenge might be how to know when the stream has finished sending data. There could be a lot of questions, and we will see all of them in a little while.

Reactive Streams is used to perform Reactive Programming in Java. It is an API specification or, say, low-level contract given by the collaborations of various companies like Pivotal, Netflix, Red Hat, Twitter, Lightbend (previously known as Typesafe), Kaazing, Oracle, and many more. You can consider the Reactive Streams API to be just like JPA or JDBC. The actual implementations are provided by various vendors.

For example, JPA specifications have various vendors like Hibernate, TopLink, Apache OpenJPA that provide actual implementation. Similarly, there are many popular JVM-based libraries that support Reactive Programming like Reactor, Akka stream, Ratpack, Vert.x, and so on. They all provide an implementation of the Reactive Streams specifications, which bring interchangeability.