Event Sourcing vs. Blockchain

The Axon Framework enables developers to easily write Java applications using event sourcing. At a first glance, event sourcing has important similarities to the popular blockchain paradigm — they both are about keeping a full history of what happened in the past. As a result, we regularly get questions about how they relate. In this blog, we'll explore their similarities, differences, and potential similarities. 

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 whenever changes occur. When data gets updated, the old data is overwritten, and history is lost. Event sourcing is an alternative strategy. The state is persisted as a series of events in a place called the event store. New events get appended, but they 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 understandability and compliance; it delivers input for analytics and machine learning; and it allows us 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 Ethereum.

Event Sourcing and Blockchain: Compared

We started by observing that event sourcing and blockchain both are about keeping history. But, trying to define them 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, this includes a single application, which may be a group of microservices. In fact, 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" blockchains being a relatively novel spin-off).

• Transaction Latency

  Event sourcing is just one of the ways to implement persistence in fast, online transaction processing systems. Typical transaction latencies are measured in milliseconds with 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 a consensus being achieved. For instance, the Bitcoin block time is 10 minutes. With six subsequent blocks being a commonly used requirement to consider a transaction confirmed, this gives a delay of one hour on a transaction, although it may be shorter or a lot longer, depending on the circumstances.

• Storage Architecture

  Event sourcing relies on having a central event store. Of course, there may be replicas, sharding, etc. But, conceptually, it remains in 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 AxonDB, 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 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 the introduction of new use cases that aren't even clear at this moment in time.