Milan's event thoughts

Event Sourcing was coined around 2004 by Greg Young and Martin Fowler , while Durable Execution is somewhat a new kid in the block - first used around 2022 by Maxim Fateev, although the concept itself is a bit older and known by different names (workflow orchestration, reliable execution, etc.). Older than either, and quietly holding up much of the infrastructure we lean on every day, are Consensus Protocols, for which we owe Leslie Lamport a lot - most famously Paxos, conceived in the late 1980s and published in 1998. While marketed to different audiences and used to solve different kinds of problems, all three employ the same underlying mechanism: a Distributed Log. In this article, we dive into the details of the Distributed Log and how it empowers Consensus, Event Sourcing, and Durable Execution. Append-Only Log - what is it? A log is perhaps the simplest data structure there is: an ordered, append-only sequence of records. You add to the end, and you read from wherever you like...

Let’s explore the idea of recovering from a disaster in a Virtual Consensus-shaped implementation of the Consensus Protocol. Firstly, we’ll dive into what a Virtual Consensus brings to the table - what’s different when implementing the Consensus protocol using the Virtual Consensus approach. Then, we’ll challenge certain characteristics of the Virtual Consensus and see why they are important. And, lastly, we’ll see in which scenarios having the Consensus Protocol implemented with the Virtual Consensus approach has benefits in a Disaster Recovery. In this article, Disaster Recovery is any failure (node, network, disk, etc.) which prevents a system from providing its services - we consider this system unavailable . One example of a disaster would be a majority of nodes down in a RAFT-based system. Virtual Consensus The idea of Virtual Consensus originated from Delos , built by Facebook. I'm going to cover Virtual Consensus in very coarse detail. Jack Vanlightly did a great job explai...

Distributed Transactions (updating multiple transactional resources simultaneously) are among the hardest problems in Distributed Systems. A process updates the state of the component, then has to tell the rest of the system about it - and those two actions aren't atomic. The update lands, but the notification is lost, or the notification fires but the update is never committed.  Let’s see how Event-Sourced Workflows can address the issue by introducing transactionality between updating a workflow's progress and updating the state of the command model (which inherently notifies the world of the change). Firstly, we are going to define what Event Sourcing and Workflows are, and, finally, how they intersect. What Event Sourcing is Event Sourcing stores the full sequence of events that led to the current state needed to make the decision, rather than storing the state and overwriting it with every change. The event store (an append-only log) represents the source of truth, and t...

In software, Consistency may refer to many things - Code Consistency, Data Consistency, User Interface Consistency, etc. In this article, I am focusing on Data Consistency. Simply put, Data Consistency ensures that data remains accurate and reliable across different parts of a system. More formally, Data Consistency is one of the Database Transaction properties ( ACID ) defined as:  Consistency (or correctness) ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants.  The invariants may be enforced in various ways depending on the database system. For example, in Relational Databases, there are many ways to define consistency: constraints (primary keys, foreign keys, uniqueness, etc.), ACID properties of the transaction (Atomicity, Consistency, Isolation, Durability), referential integrity, and many more.  The common consensus (so far) of achieving consistency in Event Stores is that event streams define ...

Distributed Consensus algorithms play an essential role in any Distributed System in which a cluster of nodes must agree on a single value - usually an order of user requests. Once user requests are replicated and uniquely ordered on each node (in a replication log ), a node can apply the agreed-upon request to its state machine. If each node has the same implementation of a deterministic state machine, the state on all nodes will be the same (up to the given user request). Voila, we have achieved redundancy in our system, and if some  of the nodes fail, we still have the state available  on other nodes for users to consume.  State Machine Replication Idempotency If a node crashes and restarts, it wouldn't be optimal to have the apply process start applying requests from the beginning of time. Hence, the apply process durably stores its progress in an apply_index variable. This saves us some CPU cycles. However, a node could crash during the apply process before we ...

The problem that I'd like to explore in this article is related to multithreaded processing, and it goes something like this:  Design a component that executes tasks one after the other - there is no overlapping in processing. Tasks could be submitted by different threads. Of course, the most obvious solution would be to synchronize the execution of tasks. Each thread would try to acquire the lock on this object if possible, otherwise, it will block and wait for the lock to be released. While waiting for this lock to be released, the thread cannot do anything else. This approach creates a lot of contention and besides that, acquiring and releasing the lock is quite an expensive operation. So, it is not performant as well. However, we must admire the simplicity of the solution. Is there a more performant solution that does not block the thread which wants to execute the task?  Firstly, let's decouple task submission and task execution - a queue sounds like a perfect fit for the...

  Everybody wants to control time and change history. Even the software. Event Sourcing gives a reliable history of facts during a monotonically increasing timeline. Although people want to change history, it is not possible, despite many attempts to do so . However, in software, as well as in life, we make conclusions based on the facts we have at certain points in time. If later, we learn new facts that happened earlier, we may change our previous conclusions.  Many people wrote about temporality: Mathias Verraes , Martin Fowler , and others. There are even some database solutions that support bi-temporality: XTDB , Rails EventStore , etc. I'd definitely recommend reading these articles to get familiar with the topic. If there are so many resources, why am I writing about it? I personally think there is a lot of ambiguity about what it means for the Event Store to support bi-temporality. Will Event Store break its guarantee and rewrite history once it finds out about facts (...