Using Event Sourced entities

Cloudstate uses Event sourcing to persist state with ACID semantics and achieve horizontal scaling across entities as well as failure isolation. Event Sourced entities also allow the state of an entity can be recreated at any point in history. This is useful both for auditing and for debugging.

Rather than persisting its current state, an Event Sourced entity persists all of the events that led it to reach the current state. These events are stored in a journal. To load an entity, Cloudstate reads the journal and replays each event to compute the entity’s current state.

In contrast with typical create, read, update (CRUD) systems, event sourcing allows the state of the entity to be reliably replicated to other services and views. For a CRUD-based entity, there’s no inherent way to know whether a particular update has been replicated elsewhere. Event Sourced entities use offset tracking in the journal to record which portions of the system have replicated which events.

Event Sourced entities offer strong consistency guarantees. Akka Serverless distributes entities across every node in a stateful service deployment—​at any given time, each entity will live on exactly one node. If a command arrives on a particular node for an entity that lives on a different node, that command is forwarded by the proxy to the node that contains that particular entity. This forwarding is done transparently, your code does not need to know. Because each entity lives on exactly one node, that node can handle messages for each entity sequentially. Hence, there are no concurrency concerns relating to Event Sourced entities, each entity handles one message at a time.

If you’d like to learn more about event sourcing, the free Lightbend Academy course Reactive Architecture: CQRS & Event Sourcing is an excellent resource.

Language support

For detailed documentation on implementing Event Sourced Entities in your favourite language, follow the links below: