FAQ

How does Eventsourced persist actor state and how is this related to event sourcing?

Eventsourced appends messages to a journal before they are processed by an actor and recovers actor state by replaying them. Appending messages to a journal, instead of persisting actor state directly, allows for actor state persistence at very high transaction rates.

The library follows the event sourcing idea by storing only changes to actor state. These changes are appended to storage without ever mutating them which is a perfect basis for achieving high write-throughput and fast replication to achieve high-availability. A difference to the event sourcing concept is that the library stores changes (in terms of received messages) before they are processed by an actor whereas pure event sourced applications usually store state-change events after having successfully changed application state, or, after having verified that application state can be successfully changed (ensuring that there are no concurrent state modifications until stored events are applied). The storage concept of the library is therefore more a write-ahead log that nevertheless keeps the full history of logged messages. Both approaches can fully recover current application state as well as application state at any time in the past.

From that perspective, the library (despite its name) has a wider scope than event sourcing. It can be used to persist any message sent to an actor, regardless whether a message represents an event, a command or whatever. In other words, the main focus of the library is actor state persistence and event sourcing is only one of several possible use cases. Applications that want to implement pure event sourcing on top of the library can still do so by sending state-change events to persistent actors and use them for recovering application state. Another use case is command sourcing which can even be combined with event sourcing as demonstrated in the Eventsourced reference application.

The approach taken by the library really shines when persisting the state of long-running business processes based on the messages exchanged between collaborating actors. The core of a business process implementation is often a state machine (actor) that sends new commands to participants upon receiving and processing events. Having a unified approach to persisting events and commands significantly simplifies persistence and recovery of collaboration state.

Other good candidates for persistent actors are the stateful actors of an application's error kernel. They often maintain critical application state and delegate actions that may fail to child actors. Messages they receive from child actors as well as from other application parts are journaled, so that the state of the error kernel can be recovered at any time by replaying them, either after a crash or during normal application start.

Regardless whether the messages stored by a persistent actor represent event or command messages, the actor is referred to as event sourced actor in the user guide. Similarly, to make an actor persistent it must be modified with the Eventsourced trait.