Martin Thompson announced the second version of the Reactive Manifesto at Goto Aarhus 2014. This new edition offers subtle differences in both the naming and approaches prescribed by the original document. InfoQ was able to interview Martin shortly after the announcement and discussed the implications of those changes and the future of the reactive community. The React 2014 conference in San Francisco will delve further into the Reactive Manifesto and its implications as well as showcase the experiences of developers who are currently practice its tenets.

InfoQ: The Reactive Manifesto was well received and has gained acceptance in the development community. Why did you see the need for a rewrite?

Martin:After the original manifesto was released we received lots of feedback. Generally it has been really positive as many have begun to appreciate the changing environment of applications development. However some feedback rightly pointed out that the previous versions had been too verbose, and in places focused disproportionally on specifics. We were encouraged to make it more concise and focus on the properties reactive systems should exhibit. "If I had more time I would have written a shorter letter..." definitely applies in this case. Plus wider feedback really helps refine a focus.

InfoQ: Why now?

Martin: People like Kresten Krab Thorup made a strong case for "why now" in the manifesto. He pulled together what others are seeing with his own experience and highlighted that we are in a world where the Internet is the primary, or only, channel to market for many organisations, and he combined this with the confluence of the changes in platform in our multi-core and cloud world.

InfoQ: Did the structure of the manifesto shift? Is it written in a prescriptive instead of descriptive manner?

Martin: We wanted the manifesto to focus purely on why we now need a new mainstream approach to systems architecture, and the key properties these systems are required to offer. As part of the rewrite we wanted to be descriptive about the properties and qualities of a reactive system. The key properties being that a system should be responsive, resilient, and elastic which is fundamentally enabled by being message driven. We do not want to be prescriptive in the manifesto as to how this is achieved. The prescriptive ways in which this can be achieved can be illustrated in an appendix and via wider discussion.

InfoQ: Message Driven vs. Event Driven has subtle implications and expands the definition of what can be considered a reactive system. What drove this change in the name of this concept? Martin: Yes it has subtle but also very important implications. The importance is in how components communicate. Events are an important domain concept. They can be passed directly by function call, or they can encoded and passed in a message. Events are only one of many concepts we might wish to communicate via messages. To achieve the other three properties we wanted to highlight that it is important to have an asynchronous binary boundary. A boundary that can provide decoupling of language, location, concurrency model, and temporal entanglement. This is also the fundamental level of isolation. Given this boundary as a means of isolation it is possible contain a failure. Exceptions should not cross an asynchronous binary boundary. Errors should be passed as messages between components and handled as first class concepts. If we do not get a response from a component then we must suspect it has failed. Memory should not be shared in a mutable fashion between components. Shared mutable state is a major source of contention which prevents scaling in the multi-core world. We need to move to design approaches where we communicate to share memory, rather than share memory to communicate - the old CSP mantra. By isolating components we can avoid contention, amortise expensive costs via batching, and take a shared nothing approach that scales in the multi-core and cloud world. In striving to achieve 100% uptime it is necessary to support hot upgrade. An essential ingredient of hot upgrade is to communicate with version encoded messages between redundant components.

InfoQ: Similarly, Elastic and Scalable are not precise synonyms of each other and their difference can offer many interpretations of how to implement this concept. How does a service exhibit Elasticity in a way that Scalable could not describe?