Reactive Architecture: Benefits & Use Cases

While the term reactive architecture has been around for a long time, only relatively recently has it been recognized by the industry and hit mainstream adoption. The goal of this article is to analyze what reactive really is and why to adopt it.

Its core meaning has been formalized with the creation of the Reactive Manifesto2 in 2013, when Jonas Bon”r collected some of the brightest minds in the distributed and high-performance computing industry Dave Farley, Roland Kuhn, and Martin Thompson to collaborate and solidify what the core principles were for building reactive applications and systems. The goal was to clarify some of the confusion around reactive and build a strong basis for what would become a viable development style. Later on in the article, we will look at the manifesto more in details, but now, let’s see what is reactive?

What does reactive really mean?

Reactive programming is an asynchronous programming paradigm, concerned with streams of information and the propagation of changes. This differs from imperative programming, where that paradigm uses statements to change a program’s state.

Reactive Architecture is nothing more than the combination of reactive programming and software architectures. Also known as reactive systems, the goal is to make the system responsive, resilient, elastic, and message-driven.

A Reactive system is an architectural style that allows multiple individual applications to coalesce as a single unit, reacting to its surroundings while aware of each other, and enable automatic scale up and down, load balancing, responsiveness under failure, and more.

In Apiumhub we believe that Reactive Architecture can elastically scale in the face of varying incoming traffic. Scaling usually serves one of two purposes: either we need to scale out (by adding more machines) and up (by adding beefier machines), or we need to scale down, reducing the number of resources occupied by our application. An interesting scaling pattern popularized by the likes of Netflix is predictive scaling, in which we know when spikes are going to hit so we can proactively provision servers for that period, and once traffic starts going down again, decrease the cluster size incrementally.

As for the reactive libraries, they often resort to using some kind of event loop, or shared dispatcher infrastructure based on a thread pool. Thanks to sharing the expensive resources (i.e., threads) among cheaper constructs, be it simple tasks, actors, or a sequence of callbacks to be invoked on the shared dispatcher, these techniques enable us to scale a single application across multiple cores. This multiplexing techniques allow such libraries to handle millions of entities on a single box. Thanks to this, we can afford to have one actor per user in our system, which makes the modelling of the domain using actors also more natural.

Reactive architecture benefits

• Be responsive to interactions with its users
• Handle failure and remain available during outages
• Strive under varying load conditions
• Be able to send, receive, and route messages in varying network conditions

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes it easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than a disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

Reactive systems are the most productive systems architectures for production deployment today, said Bon”r. They allow for systems that cope well under failure, varying load and change over time, all while offering a low cost of ownership.

Reactive manifesto

Authors of Reactive Manifesto believe that Reactive Systems are:

1. Responsive

The system responds in a timely manner if at all possible. Problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour, in turn, simplifies error handling, builds end-user confidence, and encourages further interaction.

2. Resilient

The system stays responsive in the face of failure. This applies not only to highly-available, mission-critical systems any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.

3. Elastic

The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.

4. Message Driven

Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.

Reactive Architecture: use cases

Hundreds of enterprises in every major market around the world have embraced the principles of Reactive to build and deploy production systems that deliver industry-disruptive benefits for competitive business advantage. Let me give you several well-known examples:

1. Capital One redesigned its auto loan application around Reactive principles to simplify online car shopping and financing. Customers can browse more than four million cars from over 12,000 dealers and pre-qualify for financing in seconds, without impacting credit scores.

2. LinkedIn turned to Reactive principles to build real-time presence indicators (online indicators) for the half-billion users on its social network.

3. Verizon Wireless, operators of the largest 4G LTE network in the United States, slashed response times in half using Reactive principles in the upgrade of its e-commerce website that supports 146 million subscribers handling 2.5 billion transactions a year.

4. Walmart Canada rebuilt its entire Web application and mobile stack as a Reactive system and saw a 20 percent increase in conversion to sales from web traffic and a 98 percent increase in mobile orders while cutting page load times by more than a third.

The technology industry has rallied around Reactive systems to help solve some of its customers’ most complex business challenges. As today’s modern systems scale by orders of magnitude, architectures have to deal with new ways to share data among services without crashing the system.

If you are interested in reactive architecture, I highly recommend you to read these books:

• Front-End Reactive Architectures – by Luca Mezzalira
• Reactive Microservices Architecture – by Jonas Bon”r
• Reactive Systems Architecture – by Jan Machacek, Martin Zapletal, Michal Janousek , Anirvan Chakraborty

By the way, one of the co-authors of Reactive Manifesto, Dave Farley, gave several talks on this topic in several software architecture events like Global Software Architecture Summit, here you have them:

I would like to end this article with Dave’s quote which summarizes the article very well:

We need to think about new ways of architecting our systems. Old ways are built on the compromises that were imposed on us by certain performance profiles in the hardware we were all used to. And those assumptions no longer hold. Dave Farley