What is Reactive Systems Architecture?

The term Reactive Architecture has been around for some time, but in recent times, it has started gaining more interest and recognition from the software industry. Software architecture, in itself, is the art of constructing and designing high-level structures for software systems. So, it’s an important step that ensures the software meets the original requirements of the system.

In this article, we’ll try to provide some useful information regarding what reactive architecture is. We’ll first start by looking at what reactive architecture means. Then, we’ll explore the reactive principles that define the reactive architecture. In the end, we’ll examine how and why to adopt reactive architecture.

Why Reactive Architecture?

Reactive Architecture aims to provide software that should be responsive in all situations. Reactive Systems help in building user confidence by ensuring that the application is available whenever users need it in all conditions.

Here is the Goal of Reactive Architecture:

  • Be responsive to interactions with its users
  • Gracefully handle failures and continue to be available during outages
  • Strive under varying load conditions
  • Be able to receive, send, and route messages in varying network conditions

What is a Reactive Manifesto?

It is a document under the authorship of Dave Farley, Jonas Boner, Roland Kuhn, and Martin Thompson. The Reactive Manifesto was created in response to companies trying to cope with changes in the software landscape.

Multiple companies or groups independently developed similar patterns for solving similar solutions. These groups recognized the aspects of Reactive Systems individually. So, the Manifesto solved this problem by bundling all these ideas into a single set of principles, now known as Reactive Principles.

What are Reactive Principles?

The Reactive Principles refer to a set of fundamental concepts and guidelines outlined in the Reactive Manifesto. These principles are designed to help guide the development of Reactive Systems, which are systems that are responsive, resilient, elastic, and message-driven.

Here are the key Reactive Principles:

1. Responsive

The system should consistently respond in a timely fashion. Responsiveness means that problems are quickly detected and dealt with effectively. It is the mainspring of usability and utility. Systems should be able to respond consistently and quickly if possible. This consistent behavior, in turn, simplifies error handling and builds end-user confidence, facilitating further interaction with the user.

2. Resilient

It simply means that the system continues to be responsive in the case of failure. We use a few techniques like containment, replication, isolation, and delegation to achieve this. In this, we try to isolate the failures into a single component.

It ensures that the parts of the system can fail and recover without compromising the whole system. The task of recovering individual components is the responsibility of the external component.

3. Elastic

This means that the system continues to be responsive under differing workloads. Reactive Systems can react to changes in the input rate by increasing or decreasing the allocated resources to service these inputs.

Reactive Systems use reactive and predictive scaling algorithms to support elasticity. Scaling down improves cost-effectiveness while scaling up delivers responsiveness during peak loads.

4. Message Driven

The message-driven architecture provides responsiveness, resilience, and elasticity. Reactive Systems depend on asynchronous message-passing to create a boundary between components. This ensures loose coupling, location transparency, and isolation.

This boundary also provides the means to delegate failures as messages. Non-blocking communication allows recipients to consume resources only while being active, which, in turn, leads to less system overhead.

Reactive System vs Reactive Programming

It is important to know the difference between Reactive Systems Architecture or Reactive Systems and Reactive Programming, as they are quite different.

Reactive Systems: They are the ones that implement the Reactive Principles at the architecture level. The Reactive Manifesto principles are elemental to the architecture and design of reactive systems. All major components of the architecture interact reactively. They follow the principles of being elastic, message-driven, resilient, and responsive. We segregate the Reactive Systems along asynchronous boundaries to achieve this.

Reactive Programming: It acts as a support for the construction of Reactive Systems. Reactive programming takes a problem and breaks it into small discrete steps. These individual steps are then executed in an asynchronous non-blocking fashion, usually through a callback mechanism.

Many Reactive Programming techniques like RxScala, Reactive Streams, Futures, and RxJava may be used to build Reactive Systems. However, it should be noted that a system that uses Reactive Programming is not always a Reactive System.

What is an Actor Model?

It is a programming model that aids in the construction of Reactive Systems. Actor-based applications revolve around non-blocking, asynchronous message passing between multiple actors. As an Actor Model is message-driven, elastic, and resilient, it can be used to build a Responsive System.

Akka is a reactive tool that forms the foundation of the Actor Model. An actor has various properties like a message box and actor logic. The message box acts as a mailbox for receiving messages. The actor logic uses pattern matching to determine how to handle each type of message it receives. All the computation occurs inside one of the actors or across many of the actors.

Each of the actors is addressable through a unique address. The actors communicate using the same technique regardless of their location. This means that local or remote is mostly about the configuration. Thus, the Actor System provides location transparency.

Actor Model follows Reactive Principles

Location Transparency empowers the actors to be both elastic and resilient. It is elastic because, in the event of a high load, more actors on more hardware pieces can be added, giving us elasticity.

And if we need to scale down, we can remove some remote actors or JVMs. It is resilient because actors can be deployed across various hardware pieces, and even if one of those pieces fails, there are other pieces to fill in the gap. Elasticity and resilience lead to responsiveness.

The Actor Model provides services to support all of the reactive principles. Again, it is still possible to build a system with the Actor Model and not be reactive. But by using the Actor Model, along with the other tools that are based on it, you are on the right track to success.

Conclusion

Let’s 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

Leave a Comment