Milan's event thoughts

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 an entity's current state, rather than storing the state and overwriting it with every change. The event store (an append-only log) represents the source of truth, and the current state...

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 (...

Nowadays, most systems are distributed in one way or the other - just accessing a database via HTTP makes the system distributed. Not so rarely, there is a message broker in the mix which makes a good soil for Distributed Business Transactions. There is a lot of mystery about them, they get confused with ACID transactions easily. I'm going to address common myths and misunderstandings about Distributed Business Transactions and provide some options on how to handle multiple independent resources. Before we start, let's try to understand what a Distributed Business Transaction is. Distributed Business Transactions Distributed Business Transaction is a business transaction that spans at least two independent  transactional resources.  One example would be a database update and sending a message via a message broker (see Diagram 1 ). Those two resources have their own transaction management and are completely independent. Another example would be updating two different files on a...

  In Event-Sourced systems, relying on the total order of events on all Event Store nodes is comforting, and provides ease during the design and implementation. A total order of events on all nodes is usually achieved via single-leader Consensus Protocols, which, unfortunately, have a bottleneck - the leader (I explained this in more detail in my previous article ).  The main reason for writing this article is to provide a solution for the potential issue of having a single leader as a bottleneck. To be clear, this is the issue that not so many systems meet. However, it is not satisfactory to leave it open, and that's why I am going to dive into a possible solution - Leaderless Consensus Protocols. Leaderless Consensus Protocols There is this mystical land of leaderless consensus protocols - a land where there is no bottleneck of a single leader, but each node can be the leader for an append. In other words, such a cluster can take appends via multiple Event Store nodes. One r...