Event Sourcing vs blockchain

Event Sourcing and blockchain have an important thing in common: they both are about keeping a full history of what happened in the past. This is why they get compared. To better understand how they relate, let's first look at them individually, trying to summarize them in a couple of lines. After that, we’ll look at some key differences.

Event Sourcing and blockchain - individually

Event Sourcing is a pattern that can be used when designing the persistence logic of an application. In traditional, non-Event-Sourced systems, applications would store the current state to the database, updating this when changes occur. When data gets updated, the old data is overwritten, and history is lost. Event Sourcing is an alternative strategy: state is persisted as a series of events in a place called the event store. New events get appended, but don't overwrite old events. As a result, all history is maintained. The business driver for Event Sourcing is that this history has value: it enables auditability and compliance, it delivers input for analytics and machine learning, and it allows to time travel to the state of the system at a given point in time if there's ever the need to do that.

A blockchain is a data structure consisting of a growing number of records (blocks) that are cryptographically linked through hashes. Because of these links, it's very hard to modify data in old blocks, since it would require re-calculating the hashes in all subsequent blocks. This data structure can be shared between a group of participants. Assuming these participants agree on certain rules and have established a consensus algorithm (which may include proof-of-work or mining to avoid cheap, arbitrary additions to the blockchain), this data structure can be used to keep a reliable distributed ledger, where no participant has the ability to change it (assuming they don't control a majority of nodes that would allow them to impose a "consensus"). Importantly, this takes place without the need of a central trusted third party. That's a very powerful capability, which is the foundation of cryptocurrencies like Bitcoin, and perhaps even more interestingly of smart contract technology like available on Ethereum.

Event Sourcing and blockchain - compared

We started by observing that Event Sourcing and blockchain both are about keeping history. But trying to define then individually, it's already pretty clear that they don't really have that much in common! To make that more explicit, let's try to contrast them in a few specific areas:

• Purpose
  Event Sourcing is an alternative to traditional persistence strategies, with the purpose of keeping history. Blockchain is an alternative to traditional strategies of having an undisputed version of history between participants, with the purpose of eliminating the reliance on a central authority for this, and replacing it by a consensus mechanism. In other words, Event Sourcing is about having historical records in an organization, whereas blockchain is about achieving agreement on historical records between organizations.
• Scope
  Event Sourcing is applied in a smallish, protected environment. Typically, within a single application (which may be a group of microservices). Maybe, a few related applications within the same organization would share an event store - but that's it. Blockchain, on the other hand, is primarily designed to be used publicly, across many organizations and individuals (with private or "permissioned" blockchain being a relatively novel spin-off).
• Transaction Latency
  Event Sourcing is just one of the ways to implement persistence in fast, on-line transaction processing systems. Typical transaction latencies are measured in milliseconds, the bottleneck being event store transaction speed. A number of mechanisms is available to keep delays to a minimum, in particular the use of snapshotting and aggregate caching. Blockchain transaction confirmation, on the other hand, can never be truly fast because of its reliance on blocks being signed and consensus being achieved. For instance, the Bitcoin block time is 10 minutes. With 6 subsequent blocks being a commonly used requirement to consider a transaction confirmed, this gives a delay of 1 hour on a transaction, although it may be shorter or a lot longer depending on circumstances.
• Storage architecture
  Event Sourcing relies on having a central event store. Of course, there may be replicas, sharding, etc. - but conceptually it remains a single, central place. This storage can grow very large, and in principle, that doesn't matter much as server storage capacity scales pretty well these days. Dedicated event store systems like Axon Server will keep the system running fast, even when many billions of events have been stored already. By contrast, blockchain assumes that all participants have a full copy of the blockchain. That places some limitations on size. If a blockchain would grow to many TBs in size, this would make practical blockchain operations quite difficult. (At the time of writing, the Bitcoin blockchain is about 175 GB.)

These differences are huge. This immediately leads to an important conclusion: 

Event Sourcing and blockchain are not, in any way, competing technologies addressing the same problem. They both have their own value and own specific use cases!

In fact, there are quite a few Axon users that combine both technologies. In particular, there are applications that somehow interact with blockchains on behalf of end-users who don't keep their own copy with that blockchain. Event sourcing helps to keep a clean audit record of what's going on between the end-user commands and the actual blockchain changes.

An entirely different line of thought is to transfer some of the cryptographic integrity controls used in blockchain to the event store used in Event Sourcing, making it more difficult to retroactively alter events. This type of "blockchain-light" would increase the reliability of the event store as an audit log, while stopping short of being a true distributed ledger.

A problem shared between both Event Sourcing and blockchain is that having full, immutable history may be at odds with legal mandates to erase data, for instance based on the EU GDPR's article 17 "right to erasure". There are several ways of dealing with that. AxonIQ has created a solution for this based on cryptographic erasure called the GDPR Data Protection Module. While it was designed with Event Sourcing in mind, the same concept can be applied to blockchains as well.

Ultimately, both Event Sourcing and blockchain appear to be here to stay. In years to come, both will likely see an increased adoption, and new use cases that aren't even clear now.