A PersistentEntity has a stable entity identifier, with which it can be accessed from anywhere in the cluster. It is run by an actor and the state is persistent using event sourcing.

initialState and behavior are abstract methods that your concrete subclass must implement. The behavior is defined as a set of actions given a state. The actions are functions to process incoming commands and persisted events.

The PersistentEntity receives commands of type Command that can be validated before persisting state changes as events of type Event. The functions that process incoming commands are registered in the Actions using onCommand of the Actions.

A command may also be read-only and only perform some side-effect, such as replying to the request. Such command handlers are registered using onReadOnlyCommand of the Actions. Replies are sent with the reply method of the context that is passed to the command handler function.

A command handler returns a Persist directive that defines what event or events, if any, to persist. Use the thenPersist, thenPersistAll or done methods of the context that is passed to the command handler function to create the Persist directive.

When an event has been persisted successfully the state of type State is updated by applying the event to the current state. The functions for updating the state are registered with the onEvent method of the Actions. The event handler returns the new state. The state must be immutable, so you return a new instance of the state. Current state is passed as parameter to the event handler. The same event handlers are also used when the entity is started up to recover its state from the stored events.

After persisting an event, external side effects can be performed in the afterPersist function that can be defined when creating the Persist directive. A typical side effect is to reply to the request to confirm that it was performed successfully. Replies are sent with the reply method of the context that is passed to the command handler function.

The command handlers may emit zero, one or many events. When many events are emitted, they are stored atomically and in the same order they were emitted. Only after persisting all the events external side effects will be performed.

The event handlers are typically only updating the state, but they may also change the behavior of the entity in the sense that new functions for processing commands and events may be defined for a given state. This is useful when implementing finite state machine (FSM) like entities.

When the entity is started the state is recovered by replaying stored events. To reduce this recovery time the entity may start the recovery from a snapshot of the state and then only replaying the events that were stored after the snapshot. Such snapshots are automatically saved after a configured number of persisted events.