If you are a software developer, i am sure you might have heard of the term “Reactive Programming”. In this article, I am going to give you an understanding of why reactive programming?

Note : This article is technology agnostic and is mostly conceptual.

What is reactive programming?

Reactive Programming is a programming paradigm, which helps you to build a reactive system. It advocates a declarative, event driven programming approach, modeled around ‘data flows’ between computing components.

What is a reactive system?

A reactive system is a system, which has the below key characteristics.

1. Responsive – Ability of a system to respond in a timely manner
2. Resilient – Ability of a system to stay responsive even during failures
3. Elastic – Ability of a system to stay responsive under varying workload
4. Message driven – Reliance on message passing (think data flows) to communicate between different computing components in a system

The key to reactive programming is in understanding the idea of ‘Responsiveness’.

Understanding responsiveness

The word responsive means ‘quick to react‘. Responsiveness is the ability of a system to complete an assigned task, within a given time, appropriate for the task. Please note, the notion of completeness does not mean that the assigned task was successful. It could also mean that a given task could be a failure as well. A responsive system ‘responds‘ within a given time, irrespective of whether the assigned task was successful or unsuccessful.

Responsiveness is one of the primary goals of reactive programming.Let’s understand responsiveness by comparing to a man-made system.

Example man-made system

Bear with me for a moment. The below example is used to highlight important concerns, which I believe are pre-requisites for reactive programming.

Imagine a flower shop which sells the below products,

1. Standard bouquets – Prepackaged bouquets with flower combination chosen by the shop. The shop is keen to sell more of these since they can serve more customers per unit time
2. Custom bouquets – A customer can order a custom combination of flowers based on his/her preference. This product costs extra compared to the standard ones. It also incurs an extra delivery time

This flower shop employs 2 staff who have the below responsibilities,

1. Counter staff – The person responsible for accepting and delivering orders to the customer
2. Packaging staff – The person who is responsible for packaging custom orders. When there are no custom orders, he / she will work on packaging the standard bouquets when required

Given a flower shop system described above, let us define the following times which are inherent in such a system.

1. Queue Wait Time (Customer) – The duration a customer waits in the queue to place an order
2. Service Time – The duration it takes for the flower shop to full-fill an order
3. Custom order queue time – The wait time for a custom order in queue for packaging
4. Custom bouquet packaging time – The duration taken by the bouquet packager to package a custom request
5. Overall Service time – The overall duration for a customer to complete his objective. This duration is the sum of the durations 1 to 4. Note that, duration 3 & 4 above for standard product customers depend on other custom bouquet customers.

Not so responsive system

Let’s assume that the flower shop chooses the following rules for servicing its customers,

1. The counter staff will wait for the customer’s order to be completely delivered, before taking on the next customer
2. Once packaging is complete, the packaging staff hands over the completed order to the counter staff for delivery

Given these conditions , the follow are the characteristics of such a system

1. The customer queue length and time increases with more custom order requests
2. The Overall service time for a standard bouquet customer is dependent on the number of custom bouquet request before him/her
3. The number of customers the flower shop can service per hour, depends on the number of custom orders. As more custom orders come in, the less number of customers can be serviced per unit time.
4. The more the number of custom bouquet requests there are, the more idle time for the counter staff

So given these characteristics, let us ponder about the responsiveness of such a system.

This system is unresponsive, as the customers can’t expect a standard overall service time in the illustration above.

If the number of custom bouquet requests are relatively less , then they may get a better service time. However this is entirely dependent on chance, which is not a desirable property to depend on. This system is also inefficient, because of the idle time of the counter staff. This inefficient design also reduces the throughput (the number of customers served in unit time) of the system.

A responsive system

Let us relook at the above mentioned flower shop with a slight redesign of the operations. The illustration below highlights the important changes made.

Let’s make the below changes in this system,

1. The counter staff will guide the customer to a dedicated wait queue on taking a custom order
2. He/She then places the custom order to the packaging queue, and proceeds to service the next customer
3. On completing a custom bouquet request, the packaging staff delivers the package to the waiting customer, without bothering the counter staff.

Such a system will then have the below characteristics which are different from the previous one in some key aspects.

1. This system serves more customers per unit time, since the counter staff spends less time waiting
2. Quicker service time for a standard bouquet customer since queue wait time is not dependent on the custom bouquet packaging
3. More efficient, since the idle time of the counter staff is very less compared to the previous one

Overall the above system is more responsive than the previous one. Here the standard bouquet customer can expect a overall standard service time in comparison.

Relevance to reactive programming

The flower shop here serves as a metaphor for a computing system. Reactive programming emphasizes the resource oriented view of a computing system. For example the cpu cores, memory, storage subsystems etc. are all resources. These resources also have similar queueing characteristics of the flower shop mentioned above.

A typical software will use a number of these resources (cpu, memory, disc, network) to achieve its intended function. These software also interact with other software at runtime and so on. Such a system, is a network of interconnected, computing components working in coordination to achieve a bigger goal.

Which means any failure / delay due to a lack of resource availability will have a repercussion in the upstream computing component’s responsiveness.

The number of interconnected components is directly proportional to the availability and responsiveness of the computing system, unless carefully designed. A failure / delay in any intermediate component will have a direct impact on the system’s responsiveness and availability.

Reactive programming, requires you to think in terms of data flowing between computing components. This model allows you to build robust software which are responsive to delays and failures.

Responsiveness in reactive programming

Let’s now briefly look at how reactive programming proposes to solve the above mentioned responsiveness problem.

Reactive programming forces the programmer to think of a system, as a set of connected computing components which,

1. Is aware of the limitedness of resources at its disposal
2. Responds to requests in a timely fashion
3. Reacts to data flowing through them
4. Self heal by automatically resisting data flow

Conclusion

We have reached the end of this article. I hope i managed to convey the primary goal of reactive programming, which is ‘responsiveness’. Of course there is more to reactive programming. We can delve into other aspects of reactive programming in a later article. Until then, Bye for now!