The term Reactive Architecture has been there for some time. But in recent times it has started gaining more interest and recognition from the software industry. Software architecture in itself is an art to construct and design a high level of structures for software systems. So it’s an important step that makes sure that the software meets the original requirements of the system.
In this article, we’ll try to give some useful information regarding what reactive architecture is. We’ll first start by looking at what reactive architecture means. Then, we’ll look through the reactive principles which define the reactive architecture. In the end, we’ll look at 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 helps in building user confidence by making sure that the application is available whenever the users need it in all conditions.
What 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 Reactive Manifesto?
It is a document under the authorship of Dave Farley, Jonas Boner, Roland Kuhn, and Martin Thompson. The Reactive Manifesto was created as a 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, which are now known as Reactive Principles.
What are Reactive Principles?
The system should respond consistently in a timely fashion. Responsiveness means that the problems are quickly detected and dealt with effectively. It is the mainspring of usability and utility. Systems should be able to respond in a consistent and fast fashion if at all possible. This consistent behavior, in turn, simplifies error handling, builds end-user confidence. This also helps in further interaction with the user.
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 for achieving 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 recovery of individual components is the responsibility of the external component.
This means that the system continues to be responsive under the differing workload. Reactive Systems can react to the 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 load.
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 Architecture or Reactive System and Reactive Programming, as they are pretty different.
Reactive Systems: They are the one that implements 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 architecture interact in a reactive way. 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 which is usually and more often through a callback mechanism.
Many Reactive Programming techniques like RxScala, Reactive Streams, Futures, RxJava may be used to build Reactive Systems. Although, 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 helps 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 is 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 know 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 with 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.
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