Nowadays software is a critical tool in the current business. Small companies and start-ups grow and their systems with them. Customers' experience could be affected if the systems are not able to perform efficiently. The software must be available when the customer needs it, with no periods of inactivity.
Reactive systems help adapt to change
Reactive architecture provides software keeps in a very high responsive under all conditions. No matter how many customers/users are using the system or how busy is it, no matter if the system is under maintenance or even no matter if the system is failing. We all already know that we can’t avoid failures in the systems. However, we have to design systems that reduce the impact over the users in case of failure, systems that can manage these failures in an efficient way, and provide some functionalities even when they are failing.
Reactive programming is an asynchronous programming paradigm, concerned with streams of information and the propagation of changes. Reactive architecture is based on the reactive principles found in the Reactive Manifesto. If you want to know more about the reactive Manifesto you can go to its official site. The reactive manifesto was created by multiples companies which were developing similar solutions to similar problems.
Goals of reactive software architecture
The goal of any reactive system is to make it responsive, resilient, elastic, and message-driven.
Responsive: The system must respond quickly and consistently. This is the most important principle as if our system is unresponsive the customers will lose confidence and the will try to search for other alternatives.
Resilient: Fault-tolerant system. The system will keep working even if any failure occurs. This can be achieved by replication, isolation, delegation among other concepts.
Elastic: System which is able to scale up during peaks and scale down when the high demand is not necessary and therefore saving resources.
Message Driven: Messages should be asynchronous and non-blocking. A message-driven application may be event-driven, actor-based, or a combination of the two. Basically, there are not stuck messages waiting for a response.
Reactive Streams
Once known the main principles of the reactive architecture, we can continue with Reactive Streams.
Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure.
Analysing the key concepts (also some benefits we get from using them):
- Asynchronous stream
- Increase the responsiveness and performance of your application
- Concurrency
- Independence
- Data flow
- Reduced time
- Non-blocking
- No block execution, no stuck
- Use of computing resources efficiently
- No waiting times
- No deadlock
- Back pressure
- A means of flow-control, a way for consumers of data to notify a producer about their current availability
- No bottlenecks
- Don’t overload the system
- Handle read/write operations rate
Reactive streams goals
After analysing the key concepts we can take a look at the reactive streams goals:
- Handling streams of data — especially “live” data whose volume is not predetermined
- Govern the exchange of stream data across an asynchronous boundary
- Develop a low latency, high performance, and asynchronous streams
If you are interested in getting more knowledge about how these systems can be developed, some reactive streams implementation are listed below:
- RxJava “A combination of the best ideas from the Observer pattern, the Iterator pattern, and functional programming.”
- Vert.x “A tool-kit for building reactive applications on the JVM”
- Akka Streams “A toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala”
- Reactor “Reactor is a fourth-generation reactive library, based on the Reactive Streams specification, for building non-blocking applications on the JVM”
- Ratpack “A set of Java libraries for building scalable HTTP applications”
After this introduction to reactive architecture and streams, covering the most important features, we hope you consider it when a new use case is approaching.