Event Sourcing and Blockchain
Event Sourcing and Blockchain
Want to learn more about the differences and similarities of event sourcing and blockchain? Check out this post to learn more about distributed ledgers and blockchain use cases.
Join the DZone community and get the full member experience.Join For Free
In this post, we’ll evaluate the main principles of blockchain and event sourcing. Usually, blockchain usages are proposed for application areas that can be provided by traditional data storage and architectural patterns. However, we wanted to compare these principles with something more specific. like event sourcing, given both approaches explicitly share some common principles.
There is a passionate debate on social media about this topic. Perhaps, it is a good idea to compare our approach in the FEXCO API with blockchain.
Well, this is the opinion of Mr. Vinton Cerf, not ours. These beginners always pretent that they know everything.
What Is Blockchain?
According to Wikipedia: [Blockchain] is a growing list of records, called blocks, which are linked using cryptography. Blockchains, which are readable by the public, are widely used by cryptocurrencies. Private blockchains have been proposed for business use. […] Each block contains a cryptographic hash of the previous block,a timestamp, and transaction data (generally represented as a merkle tree root hash). By design, a blockchain is resistant to modification of the data. It is “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way." For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network, collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires a consensus of the network majority.
So, a blockchain is a data structure consisting of a growing number of blocks that are cryptographically-linked through hashes. Because of these links, it’s very hard to modify data in the previous blocks since it would require re-calculating the hashes in all subsequent blocks. This data structure can be shared between a group of participants, private or public. These participants agree on certain rules and establish a consensus algorithm. This data structure can be used to keep a reliable distributed ledger, where no participant has the ability to change it (assuming they do not 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.
Blockchain keywords: Immutability, Decentralization, Convention (Consensus), Event/Transaction.
What Is Event Sourcing?
Martin Fowler wrote something about this. Here, we’ll assume that he knows what he is talking about: Event sourcing ensures that all changes to an application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states and as a foundation to automatically adjust the state to cope with retroactive changes.
Event sourcing is the practice of capturing all changes as domain events, which are immutable facts of things that have happened. It is also an architectural 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. On the other side, in event sourcing systems, the state is persisted as a series of events in a place called the event store. New events get appended, but they do not overwrite old events. As a result, all history is maintained. The business driver for event sourcing is that this history has value — it enables traceability and compliance; it delivers input for data analysis; 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.
Event Sourcing keywords: Immutability, Domain, Convention, Event/Transaction, Temporal Dimension, History.
Main Comparison Indicators
It is said that event sourcing is applied in small, protected environments. Typically, this includes a single application, which may be a group of microservices. This is not true anymore. Event sourcing systems can be found in general-scope, multi-application systems covering multiple areas and regions, sharing the same policies, conventions, and rules about event/transaction handling. While most of them are still private, many others are publicly shared across partners and affiliates. Again, sharing the same rules. Centralization was a key concept in event sourcing, but the evolution of architectures, distributed databases, and multi-region Cloud IT-based systems have strongly decentralized event sourcing systems.
Blockchain, on the other hand, is primarily designed to be used publicly, across many organizations and individuals (with private blockchain systems being a relatively new thing). Does it make sense to have a private/permissioned blockchain system?
No jokes with latency. This is really important since systems MUST provide consistency and secure transactions in a fast, responsive, and robust way.
Event sourcing is just one of the ways to implement persistence in fast, online transaction processing systems. Typical transaction latency time is measured in milliseconds. A number of architectural solutions are available to keep delays to a minimum — in particular, this accounts for the use of snapshots and aggregate caching for data structures in High Availability mode.
On the other hand, blockchain transaction confirmation is terribly slow 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 common 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.
The source of trust in the event sourcing systems is multiple and verified by the consensus. The Event Store has the maximum priority in these operations that include early detection, correlation, verification, re-build, and correction.
Our approach was quite sensitive to preserve the authenticity of the events in time, allowing the verification of the data in the distributed databases by comparing the generated checksums from the data in the payloads in time. The idea is to detect ASAP inconsistencies and unauthorized changes in the distributed ledgers in the system.
The automation and visualization of these operations are the core of the system insights that any Event Sourcing system should include.
This is the key concept in both systems: immutability of events/transactions as well as the ability to trace, track, re-build, and verify their authenticity. That refers to the ability to keep, protect, and preserve the history of the system.
What Happens When We Want to Delete Data
A problem shared between both event sourcing and blockchain systems 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. We are working on the implementation of a solution for this based on immutable event erasure.
Both approaches are fascinating, and the search for useful use cases for blockchain will be more helpful for this technology than trying to apply this technology where other architectural patterns have already been perfectly met.
On the web, you'll find thousands of comparatives and discussions. However, we think the problem here is not about the technologies but about the problems the technologies are trying to solve, the skills of the technical staff, and the future maintenance and evolution.
Published at DZone with permission of Jesus de Diego . See the original article here.
Opinions expressed by DZone contributors are their own.