Leaning Towards Reactive Architecture
Why Reactive Architecture?
Reactive Architecture aims to provide software that remains responsive in all situations. Reactive Systems build user confidence by ensuring 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
- Handle failure and remain available during outages
- Strive under varying load conditions
- Be able to send, receive, and route messages in varying network conditions
What is Reactive Manifesto?
The Reactive Manifesto is a document that was authored by Jonas Boner, Dave Farley, Roland Kuhn and Martin Thompson. The Manifesto was created in response to companies trying to cope with changes in the software landscape. Multiple groups or companies independently developed similar patterns for solving similar solutions. So aspects of a Reactive Systems were previously individually recognized by these groups. So the Manifesto attempts to bring all of these common ideas into a single unified set of principles, known as Reactive Principles.
What are Reactive Principles?
- Responsive: The system consistently responds in a timely fashion. Responsiveness means that problems may be detected quickly and dealt with effectively. It is the cornerstone of usability and utility. Systems must respond in fast and consistent fashion if at all possible. This consistent behavior in turn simplifies error handling, builds end user confidence, and encourages further interaction.
- Resilient: The system stays responsive in the face of failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are isolated to a single component to ensure that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to external component.
- 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. Reactive Systems support predictive and reactive scaling algorithms to support elasticity. Scaling up is done to provide responsiveness during peak load, while scaling down is down to improve cost effectiveness.
- Message Driven: Responsiveness, resilience, elasticity is supported by message driven architecture. 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. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.
Reactive System vs Reactive Programming
It’s important to understand the difference between Reactive Systems or Reactive Architecture and Reactive Programming, because they are different.
Reactive System
Reactive Systems apply the Reactive Principles at the architectural level. The Reactive Manifesto principles are intrinsic to the design and architecture of reactive systems. All major architectural components interact in a reactive way. They follow the principles of being message driven, elastic, resilient, and responsive. In order to do this Reactive Systems are separated along asynchronous boundaries. Reactive micro services are an example of something that is built using Reactive Systems.
Reactive Programming
Reactive Programming can be used to support the construction of Reactive Systems. It takes a problem and breaks it up into small discrete steps. Those individual steps are then executed in an asynchronous non-blocking fashion, usually through a callback mechanism. Reactive Programming techniques like Futures, Reactive Streams, RxJava, RxScala can be used to build Reactive Systems. Although, a system that uses Reactive Programming is not necessarily Reactive System.
What is Actor Model?
The Actor Model is a programming paradigm that supports the construction of Reactive Systems. Actor-based applications revolve around asynchronous, non-blocking message passing between multiple actors. Because of the fact that it is message driven, it is elastic, it is resilient, it can be used to build Responsive System. Akka is a reactive tool which is the foundation of Actor Model. An actor has properties like, a message box which is a mailbox for receiving messages, actor logic which relies on pattern matching to determine how to handle each type of message it receives. All your computation will occur inside of one of those actors or across many of those actors. Each of those actors are addressable and has a unique address. Our actors communicate with the same technique regardless of location. This means that local versus remote is mostly about configuration. Thus Actor System provides location transparency.
Location transparency enables actors to be both resilient and elastic. Resilient because actors can be deployed across multiple pieces of hardware and if one of those pieces fails, there are others to fill in the gap. Elastic because if we have a high level of load, more actors on more pieces of hardware can be added giving us elasticity, or if we need to scale down we can remove some of remote actors or JVMs. Resilience and elasticity leads to responsiveness.
The Actor Model provides facilities to support all of the reactive principles. Again it is still possible to write a system with the Actor Model and not be reactive. But with the Actor Model, and the tools that are based on it, you’re further along the path to success.
Similar articles -
You can also checkout my other articles on Reactive Architecture series —
