We’ll take a quick look at the reactive system, as well as the principles and approach used to create it.
Reactive Manifesto
The Reactive Manifesto is a document that defines a set of core principles of reactive programming.
Team: Jonas Boner and team members
Year: 2013
Website: https://www.reactivemanifesto.org/
GitHub: https://github.com/reactivemanifesto/reactivemanifesto.
What is a reactive system?
Reactive systems are an architectural style that enables numerous independent services to blend into one unit and communicate in a reactive manner. Being reactive means being message-driven and being message-driven means you are communicating with asynchronous messages. Reactive Systems and our microservices have to communicate with each other in an asynchronous way using asynchronous messages.
- The Reactive manifesto principles are intrinsic to the design and architecture of the Reactive System
- All major architectural components interact in a reactive way
- Reactive Systems are separated along asynchronous boundaries

What are Reactive Principles?
Responsive
Responsiveness means any problems that occur in the system may be easily identified and resolved quickly because the system must respond in all circumstances. Consistent behavior of a system builds end-user confidence and makes a strong bond between applications and users. In case a component is not functioning properly, it won’t affect the other component’s behavior.
Resilient
The reactive system should remain responsive even when a failure occurs and that’s pretty important because if you have a system that is responsive except when a failure occurs, well then it’s not really a responsive system, especially if failures are occurring quite frequently. It needs to be resilient when a
failure occurs and needs to be able to respond to that failure and continue to operate to the best of its ability. Resilience can achieve through replication, isolation, containment, and delegation.
- Replication means multiple copies of an object and reduces the risk of data loss
- Isolation means that services can function on their own, they don’t have external dependencies
- As a result of isolation, containment ensures that any failure has no ripple effects on other services
- Delegation means that recovery is manageable by an external component. The external component monitors the system and restarts it as necessary or does whatever it needs to do to handle the failure.
Elasticity
Elasticity refers to responsiveness under load, which means that a system’s throughput automatically adjusts up or down according to resources. When resources are proportionally added or removed, the system must scale up or scale down as per load in order to conserve resources. Predictive auto scaling strategies can be used to support elasticity if it exists and suggests that there are no conflicts and no major bottlenecks.
Message Driven
Reactive systems use a “Message-driven” methodology. The foundation of message-driven is asynchronous non-blocking communications. All components interact through messages sent and received asynchronously and messages have to be asynchronous and non-blocking.
“Message-driven” architecture supports all of our responsiveness, resilience, and elasticity.
Why build reactive systems?
- Reduces latency
- Manages breakdowns
- Manage load peaks
- Is able to send, receive, and forward messages in an unreliable network
References
https://www.reactivemanifesto.org/
https://www.oreilly.com/radar/reactive-programming-vs-reactive-systems/