Reactive is not new in Software Engineering. Within few years, we have seen an increase in reactive solutions at a large scale. Let us look at what reactive programming actually means.

Reactive programming is a paradigm that enables programming for streams of data in a non-blocking (asynchronous) manner. It makes the solutions such that the system reacts to the stream of events.

The reactive programming paradigm is similar to the principle of Observable and Observer patterns. Observable being the emitter of events and observer observing on the emitted events with knowledge of steps to be taken with incoming data.

In the real world example, let’s consider a newspaper or a Netflix show. Here the newspaper or the Netflix show is what you have subscribed to, so it is observable. It emits a stream of events in form of news or shows content. In order to receive newspapers every day or new shows from Netflix, the first step is to subscribe. Once subscribed whenever an observer emits events (a newspaper publishing the news daily or an episode on Netflix) you receive it. On every new event published by a publisher,i.e. the daily newspaper or the Netflix show, you are free to act upon as an observer. In case your subscription is expired (which you can think of as an exception) you should be taking an action based on your interest. Once a Netflix show is finished, or you have read the newspaper and no longer want it, it can be notified of events being completed or being unsubscribed.

Similarly, in the software world, we can program based on events to make a more robust solution that can scale better.

The evolution of computers has had been focused on processing speed. As we have increased the number of cores, we can work on multiple processes together. We have added more cores but if we keep our programming model as a single-threaded application, we will never be utilizing processors to their full capacity. When the load will grow up, we will be scaling by adding more CPUs,yet all the CPU will be fractionally utilized. This will increase cost while we if we had coded effectively utilizing all the available cores we could have saved a lot of money easily.

Consider we have an Order from a normal e-commerce website, where we need to call different services like cart service, user service, and product services. We aggregate all these 3 calls to send back the response to our user.

The throughput of such a call will be time taken by cart service (x), product service (y), and user service(z) along with the time taken in-network calls.

Total time taken = Network Time + (x)+(y)+z()

If we execute these network calls in parallel and know when all of the calls return responses, we aggregate their responses and send an aggregated response, we can save time. In this case, the time taken will be

Total time taken =Network time+ Max(x,y,z)

This will save our time and response could be much faster. We can achieve it by already present Future and callbacks, then why do we need to look at the reactive paradigm. With the increase in network calls and callback function, slowly it will lead to a complex structure and it will become callback hell.

The reactive paradigm works with all these functions and yet keeps things simple. We will explore it in this series on Reactive Programming with Java.

In the next section, we will look at the founding principle of reactive programming which is Reactive Manifesto.