A brief overview of reactive systems

There has been a lot of buzz about reactive systems over the past couple of years. Along with the buzz comes the collection of relevant keyword salads like reactive streams, reactive extensions, reactive programming, functional reactive programming, etc. If you’ve been in the technology industry long enough, you’ve seen the cyclical ups and downs of buzzwords and acronyms from time to time. So, is all of that another soon-to-be-dated hype?

I’ve heard software engineers dismissing reactive systems as nothing more than an alias for asynchronous event-based systems, much like the way some dismiss microservices as SOA (service oriented architecture) less ESB (enterprise service bus). While technology buzzwords with reinvented meaning do oftentimes pop up, I see enough distinctive traits in reactive systems to think that the name isn’t simply another alias.

What are reactive systems?

The Reactive Manifesto describes the essential characteristics of the reactive systems: responsive, resilient, elastic and message-driven. That gives a high-level picture and sounds a little generic. In particular, responsiveness, resilience, elasticity described in the manifesto are almost standard requirements of many real-world applications these days.

Perhaps “message-driven” is the requirement that truly differentiates reactive systems from others. Under the hood, a reactive system relies on interactions via asynchronous message-passing that establishes boundaries among individual components. Such an interaction model helps pave the path toward loose-coupling both time-wise and location-wise for concurrency and distributability, respectively. In addition, it allows the system to be integrally equipped with some non-blocking mechanism to regulate data flows (more on this below).

Reactive streams

In building reactive systems, there seems to be a prominent approach in which data processing operations are, whenever applicable, formulated as compositional stream flows. That’s not part of the requirements in the Reactive Manifesto, but it could be the inherent message-driven interaction model in reactive systems that naturally favors such a stream-centric modeling approach.

Apparently emerged as a separate initiative, reactive streams can be viewed as a specific type of reactive systems that centers around stream processing, expressing compositional streams as directed graphs.

Back-pressure

One of the non-blocking regulatory mechanisms mentioned earlier is back-pressure. It may be the most sought-after functionality for systems that implement reactive streams. It’s an asynchronous feedback mechanism operating in the opposite direction of the stream towards the upstream components for load regulation.

With the built-in back-pressure regulating the stream flows in a non-blocking fashion, the system is able to operate with relatively more steady memory utilizations. Such functionality eliminates potentially devastating stack overflow problems (e.g. caused by a slow data sink) which would typically have to be countered by custom-building data buffering mechanism throughout the stream flows.

What about reactive programming?

As a programming paradigm for building reactive systems, reactive programming emphasizes formulating asynchronous programming logic as data streams, and automatic propagation of changes to values of correlated variables in the system. The languages used for such programming paradigm would provide suitable composable functions to operate on the formulated streams.

By design, reactive programming favors the functional programming style which expresses and resolves computational problems using composable functions. Nevertheless, the existence of the term functional reactive programming predates this reactive “movement” by more than a decade. FRP has a vastly different focus and centers around using functions to express behaviors over continuous time with a simple denotation semantics. Yet, it’s now oftentimes viewed as reactive programming with an explicit emphasis in functional programming.

If an illustration with code works better, I recommend reading Andre Staltz’s tutorial post which steps through the essence of reactive programming in JavaScript using RxJS.

ReactiveX

ReactiveX, a.k.a. Reactive Extensions, is an API library that enables the using of compositional operations to handle streams of asynchronous events. Extending from the observer pattern, observables and observers (which are subscribers to the observables) constitute the key ingredients in the library with a set of composable operators for filtering, transformation, aggregation, etc. RxJS and RxJava are two of the most popular implementations of ReactiveX in JavaScript and Java respectively.

Akka actors

Akka is an actor-based library targeted for building scalable concurrent and distributed applications on JVM (Java Virtual Machine). At its core are computational primitives called actors that maintain state and behavior, and communicate among themselves via asynchronous message-passing.

Written in Scala, Akka actors are by nature lightweight and loosely coupled. That, coupled with Akka’s robust routing, sharding, and pub-sub features for scalable distributed systems such as IoT, make them a great platform for building reactive systems.

Akka streams

A front-runner (and a founding member) of the reactive streams initiative is Akka Streams. It’s built on top of Akka actors and provides an extensive set of APIs for building stream topologies and processing streams in a highly compositional fashion. A recent blog post of mine centers around Akka streams and how it can be used to perform some basic text mining.

Apparently, Akka streams as a reactive initiative has been striving these days. Akka-Streams-based drivers such as Reactive Rabbit and ReactiveMongo for RabbitMQ and MongoDB have started to gain some momentum in the technology industry. In addition, Akka HTTP, which is the next generation of the Spray REST/HTTP toolkit, is also built to be stream-enabled with Akka streams as its underlying engine.

All streams oriented — in some way

With the steadily growing momentum in adopting the reactive systems initiative, it apparently has surpassed the stage of being a mere hype. It’s also evidently more than an reinvented buzzword of asynchronous event-based systems. From a technical merits perspective, I see no reason why it won’t become more prominent. Nevertheless, even open-source technology initiatives are like commercial products — good timing can quickly attract attention in the initial stage and suitable marketing can help gain on-going momentum necessary to popularize to the broader user base.

Timing-wise, functional programming has been on the rise so I’d say it’s great timing, as the programming style is favorably embraced in building reactive systems. As to marketing, I believe more intuitive and revelatory naming of the initiative would sell better to the technology industry. One could hardly grasp anything meaningful when hearing the term “reactive systems” for the first time. Although the term “reactive” addresses some aspect of the embraced change propagation in such systems, it doesn’t jump out at the audience as a signature characteristic.

With reactive systems, reactive streams and reactive programming predominantly oriented around streams, I think the term “stream” is a more revelatory keyword than “reactive.” Trading generality with simplicity and intuition, I would combine reactive systems and reactive streams as a single initiative, and replace “reactive” with something that centers around “stream.”