Reactive systems

Reactive systems is an architectural style for building distributed software that remains responsive under load, under failure, and under change. The style was codified in 2014 by Jonas Bonér, Dave Farley, Roland Kuhn, and Martin Thompson in The Reactive Manifesto, an online document that characterises such systems by four traits: they are responsive, resilient, elastic, and message-driven.

The manifesto is an architectural statement, not a programming one. It is commonly confused with reactive programming, a related programming technique. The two share a name and an emphasis on asynchrony, but operate at different levels of abstraction. Reactive programming is a tool one might use inside a reactive system, but it is neither necessary nor sufficient to build one. A service built with blocking, imperative code on a thread-per-request model can still form part of a reactive system. Conversely, an application built entirely on reactive streams can still fail the manifesto’s traits if its components are synchronously coupled, brittle, or unable to scale under load. Bonér and Kuhn drew the distinction explicitly in their 2016 essay, "Reactive Programming vs. Reactive Systems".

The four traits

The manifesto organises its definition around four traits, of which asynchronous message passing is treated as the foundation on which the other three are built.

  • Responsive. The system responds in a timely manner if at all possible. Responsiveness is the user-visible quality on which the others are judged: a system that is not responsive is not useful, regardless of how resilient or elastic it is underneath.
  • Resilient. The system stays responsive when a component fails. Failures are contained and isolated, and recovery happens without affecting the wider system. The manifesto’s resilience leans on patterns such as replication, isolation, circuit breakers, and bulkheads to keep the blast radius of a failing component local.
  • Elastic. The system stays responsive under varying load, scaling up and down automatically as demand changes. Elasticity is the name the manifesto gives to the ability to add and remove resources in proportion to load. In practice it is delivered by auto-scaling and load balancing on top of horizontal scaling.
  • Message-driven. The system is built on asynchronous, message-driven communication between components. Messages are the means by which the other three traits are realised: loose coupling via messages yields isolation, lets components be placed wherever capacity is available, and lets failures be signalled as messages rather than propagated through synchronous call stacks. This trait places reactive systems in the same family as event-driven architecture, of which it is a more prescriptive formulation.

The Reactive Principles

The Reactive Principles site, a companion to the manifesto, restates the same four traits and elaborates them as a set of design principles for microservice and cloud-native systems. Where the manifesto is a short statement of what a reactive system is, the principles are a longer, more opinionated guide to how one is designed.

Reception

The manifesto has been widely cited and has shaped the vocabulary of cloud-native architecture, but it has also been criticised. The four traits are not novel – resilience, elasticity, and asynchronous messaging were all established practice before 2014 – and the document reads to some as marketing for the Akka and Reactive Streams ecosystems rather than a precise architectural prescription. The term reactive itself is overloaded: it is used in reactive programming, Reactive Streams, and reactive systems with related but distinct meanings, which contributes to the common conflation between the programming technique and the architectural style.

See also

References

  • Bonér, J., Farley, D., Kuhn, R. and Thompson, M. (2014). The Reactive Manifesto. reactivemanifesto.org.
  • Bonér, J. and Kuhn, R. (2016). Reactive Programming vs. Reactive Systems. infoq.com.