Transactions in an Event Sourced system

In an event sourced system how do we do transactions? This is an interesting problem.

The first thing to note is that I am talking about business transactions, not database transactions. (The main difference is that in a database transaction the transaction is atomic, and cannot be seen by any process outside of the transaction whereas a business transaction can be observed whilst in progress).

If you recall that in an event sourced system any entity that can be uniquely identified and has a life cycle can be represented as a stream of events.

Well, a business transaction can be uniquely identified and has a life cycle. This means that it, too, can be represented by a stream of events and the status of the transaction (in progress, failed, succeeded) can be derived by running a projection over those events.

The business transaction can issue commands which, in turn, can append events to the event streams of other business entities and this will update the state of them returned by any projection that runs over them.

The success or otherwise of the command is then written back to the event stream of the transaction, along with any results.

What happens if a command fails? Well that depends - what do you (the business) want to happen?

It can be retried (appropriate for a transient error) or it can be rolled back. Because the entire history of the transaction is stored in the event stream of the transaction then compensating actions can be issued to undo the work already done to return the system to the state it was in before the transaction.

More importantly the event stream of the transaction can be interrogated after the fact to see if there is anything to be learned from its failure and this can form the basis of business process changes - you can even replay failed transactions into a test system to see if they now succeed.