Blockchains are very much the hype, gaining traction even within the enterprise technology portfolio; they seem to be all but a panacea to “fix” every new application that comes to mind. Contrast this with Event Driven Architecture (EDA), an old and proven paradigm, which has recently made a comeback, as the need for rapid and asynchronous dissemination of data between many components, can only soar higher in today’s increasingly interconnected and agile “Digital Transformation“. Yet are these two seemingly unrelated IT concepts really that dissimilar?

The following blog will explain both notions, highlight their similarities and differences and conclude with when to use them.

Introducing the “Contenders”

The Surprising Similarities

Even though so differently defined, these two technologies share some interesting traits!

1. Immutable System of Record

Blockchains are about immutable verified transactions. EDA is about events. Yet these two concepts, when saved into a database or other system of record, are very similar. “Events” can be seen as present on a blockchain: each transaction can be seen as a kind of event: “The event of doing a certain transaction”. These transactions also correspond quite well to real-world events: e.g. “On Monday at 12:05, Yasmin has given BTC 2 to Zeyneb” (where Yasmin and Zeyneb are pseudonyms). This transaction could be modeled as an event!

Similarly, Events – when properly implemented – should be immutable. This is part of their definition: they represent a certain situation occurring at a certain point in time. This is fixed and should not be changed by any further tampering. Future modifications of the situation are represented by new, different events (which may or may not undo the effect of the original event).

In blockchains, the immutability aspect of a transaction is inherent in the technology, the difference with events in it being enforced by the use of strong cryptography. This instead of the clean, sanitary programming and other security measures needed to keep events immutable throughout a system. In fact, events could even be recorded on a blockchain, saving them as transactions! Pushing the latter further, smart contracts also support events, and do this somewhat more directly. In a smart contract, events can be defined as the result of a function, and nodes can be made to look out for certain types of events, and react to them. Surprisingly, these events need not be saved on the blockchain itself (a hash of all function returns is saved instead). Our blockchain expert, Kristof, explains this in more detail in a previous blog.

2. Asynchronicity

Asynchronous Communication is used between the nodes in a blockchain network to transmit new blocks to other nodes. It happens when it happens: when there have been a number of transactions and a new block can be validated by one of the nodes.

In a similar manner, Events are propagated asynchronously to all interested parties within an EDA. There is no reply immediately following a request. Once a subscriber has registered to receive notification of a certain type of events, it will receive them whenever they happen, and as fast as the publisher, along with the underlying middleware and network, will allow.

So on a more abstract level, both of these technologies do the same thing: they use asynchronous communication to transfer information between nodes that are part of a (distributed) system. This allows the partaking systems to act more independently of each other, greatly enhancing the beneficial aspect of loose coupling in computer systems.

3. Eventual Consistency

Besides asynchronous communication, (which is related to this part), both technologies, to a certain degree, practice another principle in like manner: the principle of “eventual consistency”. Roughly, according to the CAP theorem, this principle means sacrificing some immediate Consistency in order to obtain Availability and Partition tolerance more cheaply.

The reason for this is that the network, as well as the individual nodes, can go down without causing a fatal error for the distributed system as a whole. When the part of the network of nodes that was down is back up, they will be made consistent with what has transpired on the online part of the network so far. This could, of course, take a while.

In any case, even when no parts of this network go down, it might take a while for a change to propagate throughout the entire system. Hence, the eventual state of consistency. This is ok, even for transactions, as long as mechanisms are in place to deal with any temporary inconsistencies.

In blockchain, eventual consistency is implied in the distributed and delayed transactional nature of the technology. It is a crucial part of the technology: blocks might take a while to propagate throughout the network, especially when using big blocks and extended networks. This, however, does not prevent the network from continuing to operate.

It is the same in an event driven system, but we have to do some extra work to achieve the same result. When we want great resiliency to failures, we have to make sure that, should a subscriber be out of the game for a while, it can “catch up” on the events it missed. Likewise, the event system should cache any events in case of network failure and keep trying to send them to all subscribers, until the connection can be re-established. There should also be some bookkeeping to see which subscribers haven’t received their events yet, and subscribers should mind if they receive events in correct order. Luckily, some of this work can be simplified, if we make events idempotent: this means receiving the same event twice has no additional side effects. Doubles are also easy for a subscriber to check, since events are unique and usually also have unique timestamps or IDs.

The Big Difference?

Obviously, there are some semantic differences: EDA is a way for services and applications to communicate, whereas blockchain technology is more about the security and storage of their transactions. But the main difference is the trust issue: blockchain allows transactions between parties having less than 100% confidence in the ability of the other parties to correctly handle the data. In the case of events, we have no cryptographic guarantee that the events we are transmitting will be handled correctly.

The Moral of this Story: Is there a winner?

I often see blockchain solutions being forwarded to enable and improve communication of certain “transactions”, or “information” – but we might as well just call these “events” – between different parties. Usually, greater resiliency to failures because of the distributed nature, the resulting interoperability between independent parties using the same blockchain technology, and the improved agility resulting from the asynchronous nature of the communication, are acclaimed as great and “new” benefits. This is partly what prompted me to write this blog. I feel that, in a lot of cases, these solutions would greatly benefit from relying on Event Driven Architecture (and other effectual design principles) instead!

So when should we use blockchain technology? The answer lies in the big difference: Trust. When tamperproof transactions are needed, because the communicating parties cannot fully trust each other or a central party; or when contracts need to be enforced cryptographically for the same reason, blockchain then becomes an ideal PART of the solution (but the system might still benefit from the use of events, among many other “digital transformation enabling” technologies). For a more detailed model on when or when not to use blockchain, see the decicion model made by my colleague.

In any case, these two technologies are both very important evolutions, but they are dwarfed in usefulness and transformation potential by another: Application Programming Interfaces. APIs increasingly form the basis of any good digital platform, and are the preferred way to let applications and services communicate, and businesses interoperate. The so-called API Economy has already grown vigorously, and this trend will not stop any time soon. Events may even be transmitted over APIs (an example being Google’s Pub/Sub API). And Blockchain platforms, of course, should also offer reusable APIs to allow their easy exploitation. More on APIs can be expected in future blog posts.