Introduction to Reactive Architecture

Reading Time: 4 minutes

This blog talks about the core principles behind Reactive Architecture. It introduces the reader to why we need Reactive Systems, and what problems they are trying to solve. It also contrasts Reactive System with Reactive Programming, showing how they relate, and how they are different.

Why Reactive System

As rightly mentioned in Reactive Manifesto,

Today’s demands are simply not met by yesterday’s software architectures

Over the last decade a lot has changed in software development including below:-

• Size of deployments
• The volume of data being produced and handled
• Faster release cycle to ship new functionalities quickly
• Close to 100% availability
• Milliseconds response time
• The application should be resilient
• Support of elasticity
• Cloud-based clusters
• And there could be more depending on the use cases

The above points are highlighting technical problems which are consequences of modern user’s expectations. So the actual change is that modern users have come to rely on software to do their jobs. Think about what is the impact on a person if a critical service is down for a few hours? Think about yourself, for example, you are blocked with your work due to the unavailability of google, stack overflow, GitHub, etc for a few hours. It may have a huge impact on your work if you use them regularly. But if it’s something that you use less often then it won’t have much impact on you. Also, it is an important factor that how much time software takes to respond because modern users don’t want to wait for a response.

The Goal

Considering the modern user’s expectations, a software solution should address below technical requirements:-

• Scalable enough to support from 1 to millions of users – Applications should be able to handle future user base.
• Utilizes only required resources to support current load – Build the system in a way that we can deploy additional hardware for peak season, and release that hardware after the peak is over.
• Handles failures with negligible effect on the user – Failures In Systems are inevitable. Therefore the system should be capable to handle failures gracefully and should continue to provide other functionalities that are not impacted by the failure.
• The load can be distributed across hundreds/thousands of nodes – Designing a system to run across multiple nodes can help in minimizing the impact of failures on users.
• Maintains a consistent level of quality and responsiveness

The Reactive Principles

Responsive

• A Reactive system consistently responds in a timely fashion.
• Responsiveness is the primary goal of Reactive Principles.
• Responsive systems build user confidence.

Resilient

• Resilience provides responsiveness, despite failures.
• Achieved through replication, isolation, containment, delegation
• Failures are isolated to a single component.
• In case of failure, the external component does recovery and replication ensures high-availability.

Elastic

• Elasticity provides responsiveness, despite increase (or decrease) in load.
• The predictive auto-scaling technique can be used to support elasticity. Scaling up provides responsiveness during peak while scaling down saves cost.

Message Driven

• Responsiveness, Resilience, Elasticity are supported by Message Driven Architecture.
• Messages are asynchronous and non-blocking.
• It provides loose coupling, isolation and location transparency.
• Resources are consumed only while active.

Reactive Systems Vs Reactive Programming

In the above diagram, Reactive Programming techniques have been used to develop micro-services. Reactive Programming is frequently used to build a Reactive System but using Reactive Programming does not mean that a Reactive System will be built unless it has not followed Reactive Principles.

Reactive System

Reactive Systems, in a nutshell, is an Architectural and Design pattern of building large scale, responsive, resilient, self-healing systems where individual components talk to each other over non-blocking Asynchronous Messaging.

• The Reactive Manifesto principles are the core foundation of design and architecture of reactive systems.
• All major architectural components interact reactively
• Reactive systems are separated along asynchronous boundaries.
• A Reactive System must be deployed on a cluster of machine nodes.

Reactive Programming

• Reactive Programming can be used to build Reactive Systems.
• It breaks problems into small and discrete steps.
• Steps are executed in an asynchronous/non-blocking fashion, usually via a callback mechanism.
• Examples are Futures/Promises, Streams, RxJava/RxScala
• A system that uses Reactive Programming is not necessarily a Reactive System.

The Actor Model

• The Actor Model is a programming paradigm that is used to build Reactive Systems.
• All computation happens inside of Actors.
• Each Actor has an address.
• Actors support Location Transparency through Message Driven approach.
• Location Transparency enables Actors to be resilient and Elastic.

References