Reactive system

The word reactive has become popular today and has different meanings for different people, such as lightweight, real time, asynchronous, streaming, and so on. Reactive, in broader terms, refers to a set of design techniques or principles, and is a way to consider the system architecture in a distributed environment. It comprises tooling, design methodologies, and implementation procedures. 

The analogy of a team can be used to describe a reactive system: individual players working with each other to achieve a desired goal. The interaction between the components is the main quality that differentiates a Reactive System from other systems. Components can operate individually or still work in harmony with others to achieve the intended result as a whole system. In other words, it is the system design that allows individual sub-applications to form a single logical system, perform specific tasks, and remain aware of each other. This enables decision-making, like load balancing, scaling up and down, failover mitigation, and so on.

While talking about reactive topics, mainly in the context of software design and development, people generally use the terms Reactive System and Reactive Programming interchangeably, although they are not exactly the same. A reactive system is message-driven and associated with distributed process communication over the network, whereas Reactive Programming is generally event driven and handled locally.

A Reactive System is considered to be the same as an asynchronous message-based system by many software engineers. But as per the reactive manifesto, the Reactive System is an architectural way of developing a distributed system in a responsive style. It has the following essential characteristics:

• Responsive: It suggests a system should process and respond to a request in a reasonable time.

• Resilient: It suggests that even in case of failure, the system should remain responsive. In short, any kind of error should not put a system in a non-responsive state. All possible factors that may cause a system error must be well handled without causing a system halt.
• Elastic: A system should stay responsive even with a variable load. It should be flexible to scale up and down based on the load, and handle it with reasonable resource usage. To achieve this, the application must be designed in a way to avoid any central bottleneck.
• Message-driven: Components within a Reactive System should interact with each other with asynchronous message passing. This brings a loose coupling between components, isolation in responsibility, and transparency in location.

Among these characteristics, responsiveness, resilience, and elasticity are the standard requirements for almost every real-world application today. They look simple and straightforward, but are tricky to implement. It is the message-driven requirement that distinguishes a responsive system from others.

A Reactive System uses an asynchronous message-passing mechanism to interact among components. It also furnishes a non-blocking mechanism to control the data flow. While building a Reactive System, at all relevant points, the data processing operations are composed as stream flows. In short, a Reactive System is focused on stream processing.