What's the difference between reactive programming and event driven architecture?

Question

What's the difference between reactive programming and event driven architecture?

Is reactive programming a way of implementing event driven programming?

Answer 1

Reactive Programming

A number of people have identified an increasing importance of a certain combination of desired properties for a certain kind of modern large-scale software systems. In concert, these properties satisfy typical non-functional requirements related to scalability, flexibility, robustness, ressource consumptions etc. This emerging notion has been coined reactiveness and the set of properties that constitute reactive systems has been defined in the reactive manifesto. The main characteristics are: responsiveness, resiliency, elasticity, and being message-driven. Currently, this is probably the most widely agreed-upon definition of reactive systems. Based on this general notion of reactive systems, reactive programming can be assumed to refer to any paradigm, pattern or technique that facilitates the realization of these properties in software.

Having said that, on a more technical level, reactive programming currently is understood as a programming model that has traditionally been known as dataflow programming that is having a renaissance because it is leveraged in an increasing amount of programming languages, frameworks and libraries to provide the aforementioned properties.

The systems from which the properties that constitute reactive systems have been derived typically make use of a variant of dataflow programming in which explicit handling of messages between components facilitates fault-tolerancy, the handling of back pressure and enable efficient use of ressources in highly dynamic settings by non-blocking communication.

Event-Driven Architecture

Event-driven architecture is a rather vaguely defined umbrella term for architecural patterns that certain people have identified as of increasing usefulness for certain applications. In this case, the notion largely stems from patterns that have emerged in the community of enterprise software in which microservices have emerged as a decomposition and deployment pattern to provide certain organizational benefits, i.e. to help distribute work within large projects.

While many classic concepts in software development such as object-oriented programming can be considered event-driven - communication between actors can be considered as events - it is especially this incarnation of designing an application by considering events as basic building blocks that is currently understood as event-driven. Often times people also associate with the term several patterns that extend this basic idea such as event-sourcing, and CQRS to provide several benefits that currently appear benefitial for certain applications.

Comparison

In comparison, at the heart of both notions lies asynchronous communication to decouple components. Events and messages are related notions, mostly differing in the intent that is emphasized by each term. As such they are a common ingredient of both notions. In a strict sense, being event-driven, today, is a prerequisite for being responsive. Personally, I can imagine that other paradigms may emerge to achieve the desired behavioral properties of reaponsive systems.

While the reactive manifesto emphasizes the above mentioned quality attributes related to how the system behaves at runtime and responds dynamically, event-driven architecture focuses on how a system is decomposed and how its parts generally interact. In this sense, the perspective of reactive systems is a rather behavioristical one, even though it assumes certain properties related to its internal behavior, my impression is that these internal properties may be accidental in nature, i.e. the desired behavioral properties could be achieved by different means.

Each notion currently takes a different perspective on a software system, comes with a different set of typical associations, emphasizes different aspects and focuses on achieving different goals. However they will likely keep being recoined and might diverge or converge as the notions evolve.

Answer 2

Event-driven architecture (EDA) is an architectural pattern that promotes the production, detection, consumption of, and reaction to events. They are usually broadcasted through notification messages. This explains why EDAs often leverage the messaging integration style which relies on some sort of Message Broker to implement a topology known as Hub-and-Spoke. There are many well-known examples of either on-prems or cloud-based message brokers: RabbitMQ, NATS, Kafka, IBM MQ (former MQSeries), MSMQ, Amazon SQS and SNS, Azure Service Bus, and so on and so forth.

Is reactive programming a way of implementing event driven programming?

Yes, it is, although not the only one. Reactive programming is a declarative, event-driven programming paradigm concerned with data streams and the propagation of change. It is the availability of new information that drives the logic forward rather than having control flow driven by a thread-of-execution. It supports decomposing the problem into multiple discrete steps where each can be executed in an asynchronous and non-blocking fashion, and then be composed to produce a workflow — possibly unbounded in its inputs or outputs.

It began to receive special attention in the mainstream when Erik Meijer, at Microsoft, created in 2011 a reactive programming framework for .NET called Reactive Extensions, a set of tools allowing imperative programming languages to operate on sequences of data (data flows) regardless of whether the data is synchronous or asynchronous. In a matter of years, Reactive Extensions (aka Rx) was ported to several languages and platforms, including JavaScript, Python, C++, Swift, and Java.

In the JVM world, Reactive Streams started as an initiative in late 2013 between engineers from Pivotal (now VMware), Netflix and Typesafe (now Lightbend).

The fundamental idea behind reactive programming is that events are data and data are events.

Reactive programming is a paradigm that can be used to implement building blocks, therefore its scope is within components/services. EDA, being an architectural style, is all about the interaction between components/services.

Answer 3

Reactive programming - at an abstract level - deals with decoupling flows using asynchronous data streams. However, pretty much the industry standard for achieving asynchronous data streams is through event-driven paradigm, and most of the Reactive implementations use this approach.

If there is a better approach to create decoupled flows, then Reactive programming using that approach would be possible too.