Introduction to software architecture: what is reactive programming?

Some of you might ask,” reactive programming!!, what in the world is that?”. So, let me take a moment and explain this concept the best way I can. Here goes, why this topic? Three reasons really.

• The first is that reactive programming is becoming ubiquitous. Nowadays if you write any web service or mobile app, or really any large system with a real-time component, then knowing the reactive programming techniques is essential.
• The second reason is that reactive programming really builds on functional programming. In fact, if you spend most of your time reviewing some of the more advanced concepts of functional programming, this will lead naturally into the reactive programming content.
• Third, I’m really happy that I could share a thing or two that I have learned from many of you in the field, mostly from stalking your social media accounts and reading your interesting insights on this topic.

Reactive programming describes a set of programming patterns and techniques that have become increasingly important over the last years. And the reason for that is mostly driven by a change in requirements.

A few years ago, a typical large installation would have tens of servers. response times would be measured in seconds. There would be maintenance downtime, a couple of hours per month, say. And data volume would be measured in gigabytes.

Nowadays, a large server installation or cloud installation would have thousands of nodes. Users expect sub-second response times, response times in milliseconds. There should be no maintenance downtime, the system should be available 24 seven and our data volume has easily reached a terabyte and is going into the petabytes.

So these new requirements also need new architectures. The classical architecture is optimized by something like the Java Enterprise architecture. It consists of managed servers and application containers. What you see now is more and more a shift towards so-called reactive applications that are event-driven, (hint: remember Newton's third law)? and that makes them also scalable, resilient, and responsive. When I did a google search on the meaning of “reactive” The Google dictionary, defines “reactive” as being readily responsive to a stimulus.

What we mean by that in the world of software systems is a system that can react to events, so it’s event-driven. And the system should also be able to react to changing amounts of loads, system load, which means it should be scalable. Furthermore, such a system should be able to react to failures and we call that resilient. And finally, and probably most importantly, the system should react to its users. It should be responsive.

Now, being event-driven is a technical property that enables the properties of being scalable, and being resilient. And all three properties together enable systems that are responsive to the users.

Event-driven.

Traditionally, concurrent software systems were composed of multiple threads, communicating with the shared and synchronized state. That led to a very high degree of coupling, and also such systems were hard to compose. Event-driven systems, by contrast, are composed of loosely coupled event handlers. Events in such a system can be handled asynchronously. They do not incur any blocking. And because there’s no blocking, that means that typically resources can be utilized much more efficiently.

Scalable

An application is scalable if it’s able to be expanded according to its usage. And typically we distinguish two directions of scaling. They scale up which means they make use of parallelism in multi-core systems, which become more and more common in computers today, and then their scaling out, which means we make use of multiple server nodes of an, in a data center, or in the cloud. Important for scalability here is always to minimize shared multiple states. Because we will see that that actually has implications on the ease and the efficiency of scaling. Important furthermore for scaling out is the property of location transparency. What that means is that it shouldn’t matter where a location is located. It could be at the same computer as a client, or, at some other computer across the internet. The functionality should always stay the same. The other important property for scaling out is resilience because once you have multiple nodes, some of these can fail. And the system has to cope with that.

Resiliency

An application is resilient if it can recover quickly from failures. Such failures could be software failures such as throwing an exception, or hardware failures, a computer going down, or maybe connection failures, an internet connection going down. Typically, resilience cannot be added as an afterthought, it needs to be a part of the system design from the beginning. Important techniques for constructing resilient systems are, keeping your components loosely coupled. Having a strong encapsulation of mutable state. And having pervasive supervisor hierarchies.

Responsive

Finally, an application is responsive if it provides a rich, real-time interaction with its users even under load, and in the presence of failures. Response of applications can be built on an event-driven, scalable, and resilient architecture. That doesn’t automatically lead to a responsive application. You still need to pay careful attention to algorithms, system designs, including backpressure, and many other details. But being event-driven, scalable, and resilient is important some would argue, even necessary building blocks to arrive at a responsive application.

Final thoughts, Reactive programming is an interesting topic, I believe as a software professional, it’s not only important to know about this to impress your colleagues at cocktail parties, but also necessary in our every-day attempt to build better software. I hope you enjoyed the read, this is my two cents' worth of thought on this beautiful topic.