Bi-Temporal Event Sourcing, who cares?

-

 

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 (events) that happened before the latest event in the Event Store? Let's find out!

Bi-Temporal Event Sourcing

Before we begin, let's quickly sum up what bi-temporal Event Sourcing is. Essentially, there are two timelines: system timeline and valid timeline. Events on the system timeline are ordered by the time the system found out about them. A valid timeline keeps events in order they actually happened in the world (see Diagram 1).

Diagram 1

In this example, we have a bike rental application. Users can rent a bike but also can report a broken bike. Both of them have a field describing the exact (valid) time in the "real world" when they occurred. The upper diagram shows the ordering of events based on the system timeline - the order in which the system has found events. Firstly, the bike was rented out and then it was reported broken. However, the valid time of the "bike reported broken" event is before the valid time of the "bike rented out" event. The system shouldn't have rented out a broken bike!

So what?

The system already decided to rent out the broken bike. Would inserting the "bike reported broken" event before the "bike rented out" event fix the fact that the bike was rented out? Of course not. Compensating the renting action would.

Just by following the event stream, we are going to learn about these facts and we are going to adjust our Command and Query models accordingly.

What's the use of a valid timeline?

Another example that comes to mind is the collection of card transactions by the end of the day. Let's say that we record all transactions for the current day after midnight (basically the next day, or some other day when they are ready). The valid time of these transactions would be the day they actually happened. We already saw that if we have Query Models that are always tracking the event stream they are going to learn about the transactions in the correct (valid) time. 

In cases when we want to retroactively provide a different card transaction report for the day that happened a few years ago, it would be beneficial not to replay all events in the Event Store*. Also, if we don't durably persist Query Models, we'd like to build their states on-the-fly. Anyway, we are talking about replay performance here. In those cases, it would be great if Event Store could select events based on a valid timeline fast. 

In order to support faster reading based on the valid timeline, Event Store should build a temporal index for the valid timeline. It shouldn't rearrange the event stream, or store two streams ordered by different timelines.

Conclusion

Bi-temporality is just a different view of the same event stream. It has nothing to do with changing history, inserting events in the past (or future), etc. Event Store could support faster reading by implementing a temporal index for the valid timeline, but it's just an optimization.




* We need to replay almost all events since we are not sure when the system stopped receiving transactions for the specific card.

Location: Novi Sad, Serbia

Comments

Post a Comment

Popular posts from this blog

Lock-free Exclusive Processing

-
Image
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
Read more

Ordering in Event-Sourced Systems

-
Image
In a utopian world, Event Store will write events to the disk in the exact same order in which they have happened in real life. However, computers are not so good at observing things by themselves (yet), we (still) must tell them what to do. Hence, we must provide a way to deterministically order events inside the Event Store.  A naive approach would be to attach a timestamp to each and every event and use it for ordering. The reason for its naiveness lies in the difficulty of synchronizing clocks across different machines in a distributed system. As a consequence, we mustn't rely on timestamps for ordering . Since we also cannot impose ordering of events sent by different Event Store clients among them, the only thing left is to accept the ordering of received events by the Event Store. In other words, the order in which Event Store receives events is going to be the order of events written to the disk. This means that two events could have happened in one order in reality, but t
Read more

Myths about Distributed Business Transactions

-
Image
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
Read more