Introduction to “Reactive” Nature of Distributed Systems
The term “Reactive” is an overburdened one, refers to different things as this “buzz-word” often heard with Reactive Design, Reactive Systems, Reactive Application, Reactive Architecture Pattern, Reactive Messaging, and Reactive Programming. In this article we will glance at “Reactive Systems” and why should the modern business needs them desperately.
In the digital era of cloud computing and the Internet of Things, systems and applications are bound to deal with the extensive volume, velocity, and variety of data to tackle real-world scenarios. The challenges being faced by the enterprises today are way different from the ones that they faced a decade or two ago. Also, the user requirements have brought in many changes in the traditional software applications and demand the systems are highly available, more resilient, flexible, and fault free.
The software systems have to evolve accordingly to meet the modern demands from the digital world and the typical three-tier applications could not be able to cope up the pace.
Today’s demands are simply not met by yesterday’s software architectures
What does Reactive mean?
“Reactive” is a set of design principles to build a robust loosely coupled system by keeping cohesive architecture and design in mind to implement it in a distributed environment where implementation technique, patterns, and tooling are components of a larger whole.
In a Reactive System, the interaction between various components and services makes the real difference. It’s highly sophisticated to operate independently yet act in harmony to get their desire result.
In a nutshell, it is an architectural pattern that enables to build a fault-tolerant, responsive, load balancing, resilient, and highly available with auto-scale up and down system where the functionally decomposed components communicate with each other over asynchronous messaging.
Reactive System Benefits:
It helps applications that are trying to solve today’s problems to be
· Fault-tolerant — handle and recover from failures on its own
· Highly Responsive to users requests and responses
· Better performant under dynamic load conditions
· Able to transact messages in varying network conditions.
Systems that are built as reactive in nature are more flexible, high cohesive, loosely-coupled and it manifests greater elasticity when dealing with ever-changing workload demands and resiliency when any of its parts fail. These help enterprises amenable to change of the tech stack, tools, and cloud platform to evolve products faster and easier
Reactive System Principles:
Responsive:
The system should strive to respond in a timely manner even in case of heavy loads or failures if at all possible. This is one of the essential principles when creating large-scale distributed microservice systems and particularly if any of the components interacting with services that are residing out of the caller’s control limit. The systems need to handle requests in reasonable time and deliver a consistent quality of service to requesters, it reacts quickly and consistently to events that are occurring in the system. In this way, it simplifies error handling and gives a better user experience.
Elastic:
Scalability and elasticity are often used interchangeably to mean the system should be reactive and responsive under any load conditions. The systems should be able to take a call to see the resource allocation depending upon the incoming traffic level. A reactive system should determine the necessity to scale up or scale down or scale out the resource count. The system should also ensure there are no contention points or any bottlenecks which prevent the sharing of a load to the replicated components.
Resilient:
“Architecting for resilience — strategies and technologies for today’s intelligent organization”
(Gartner Summit’s 2020 theme)
Resilience means the system should respond instantly in case of any kind of failure and there shouldn’t be any impact on user experience and the system should behave seamlessly. The failure in one component should not lead to a cascading effect that indulges to bring down the entire system. If a system is not resilient, it will be unresponsive after a failure. So it should be capable to gracefully handle any failures.
Resilience can be achieved by
- Replication: High availability can be attained via replication. e.g — Master node replication of cache cluster
- Containment: Failure should be contained within the same component or service. Failures are contained within each component, can trigger a default response to the caller
- Delegation: Component or service recovery should be delegated to another component.
- Isolation: Components of the system should be isolated to ensure partial failure could not bring down the whole system and it can recover independently. The system can fail and recover without compromising the entire system.
- Circuit Breaking: Detect failure and enfold the logic of preventing it from recurring and unexpected system difficulties
Message Driven:
Reactive System components or services communicate through asynchronous, non-blocking IO methodology of messaging that allows a boundary between components. This asynchronous boundary makes it possible to have loose coupling between components and ensures isolation and location transparency. The isolation property makes the system more resilient as a failure in one component does not affect other parts of the system. Since the communication is asynchronous, components do not wait for a response from other parts of the system and that’s the way components work independently even when any components fail.
Conclusion:
In a real-time scenario, with IoT for Omni-channel support delivery it has become imperative for innovative businesses to handle billions of requests and responds in milliseconds to delight the customers. Enterprises cannot bestow to have legacy static architecture and they need to adopt a reactive model to better serve the dynamic needs of customers. It is time to apply the characteristics discussed above consciously when you think of designing any system that needs to scale and handle a huge volume of traffic.
What’s Next?
Now, we learned the characteristics of the Reactive System and the need to take advantage of it in the competitive business world. In my next blog, I will talk about some specific patterns and design approaches to do a low-level design of the reactive system’s components. I’m sure those will be handy to keep in your bookmark to build some high intensive products.
Thanks and happy reading !!
