A little over a year ago, a group of us published the Reactive Manifesto as a way to address new requirements in application development and provide a common vocabulary to discuss complex concepts. To date, the Manifesto has received over 6,813 signatures and has sparked what I consider to be a healthy debate in our community about what the principles for modern application infrastructure might be.
When we launched the Manifesto in 2013, we established these as Event-Driven, Scalable, Resilient and Responsive. While I think these were all important pillars, after some internal debate and feedback, we’ve decided to update the Manifesto to more accurately reflect the core value of Reactive design.
For example, there was concern that Event-Driven might be adjusted to Message-Driven, since Reactive Systems rely on asynchronous message-passing to establish an async boundary between components. Ultimately, we (Dave Farley, Martin Thompson, Roland Kuhn and I) believe that by switching from Event-Driven to Message-Driven, we can more accurately articulate and define the other traits. The difference being that messages are directed, events are not—a message has a clear addressable recipient while an event just happen for others (0-N) to observe it.
The other nuance is replacing Scalable with Elastic. I think this adjustment should make sense to most readers familiar with modern workload patterns. Truly Reactive Systems should react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs, not just expanded according to its usage (which is the definition of Scalable).
So, taking these new descriptors into consideration, we can now define Reactive Systems as:
Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.
Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems—any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
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. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
Message-Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.
As always, we welcome your feedback and input on the Manifesto. This is intended to be a living document, capable of evolving with the times. We have rewritten the Manifesto to further help us achieve our goal of having an accurate, precise and thoughtful definition of Reactive Systems principles and design requirements; the new version is more concise, more coherent and tells a better story, in my opinion. I hope you’ll join me, and the rest of the community around Reactive, in promoting these principles as a practical common core for modern infrastructure.
If you’re interested in learning more about Reactive, I encourage you to read the full Manifesto and check out the upcoming React Conf in San Francisco. The event is pulled together by developers at the heart of the Reactive Systems community, and aims to provide a coherent and practical journey through the Reactive principles and practices.
