Choosing a state model

The state model of an entity determines how Akka Serverless stores and manages its data. Choosing a state model impacts both how you implement the entity and its behavior at runtime. In contrast, the service API responds to commands that are independent of the entity state model.

Akka Serverless supports Value, and Event Sourced state models:

  • Value Entities support the familiar CRUD (Create, Read, Update, Delete) model of relational databases, offering the traditional approach to persistence—​state as a single, complete unit.

  • Event Sourced Entities store each update as an event, which together build the state of the entity.

For both types of entities, Akka Serverless enforces concurrency. It processes requests to the same entity instance sequentially. The next request in line will not be processed until the state update from the previous command finishes.

Once an entity is active, Akka Serverless does not need to re-fetch its state for every request. Because Akka Serverless proactively manages the state, you need not worry about "lazy loading" or other performance techniques.

For each state model, Akka Serverless leverages a well-suited back-end data store. The data store type is not configurable.

The Value state model

Value Entities only persist their current state. The following diagram shows how the Akka Serverless proxy persists state for a Value Entity:

value flow

Once an entity with a particular ID has been instantiated, Akka Serverless caches its state and subsequent requests can be satisfied without accessing the data store. After an entity has been idle for a period of time, Akka Serverless passivates it to conserve resources.

The Event Sourced model

Event-sourcing involves capturing changes to data, as opposed to overwriting existing values. For example, a bank tracks account debits and credits, rather than just recording the balance. In case of an audit, a bank can reliably point to each transaction that led to the current balance. Similarly, in an event-sourcing system, the changes to data can be replayed in the case of failure, or when spinning up new services to handle load.

Akka Serverless Event Sourced Entities store events in a journal. Different services can start reading the journal at different points. This results in what is called "eventual consistency". When all interested parties have read all the entries, the system is consistent—​they all have the latest data. Before that, some parties might be behind for a short time, but they are guaranteed to catch up.

event source flow

Once an entity with a particular ID has been instantiated, Akka Serverless caches its state and subsequent requests can be satisfied without accessing the data store. After an entity has been idle for a period of time, Akka Serverless passivates it to conserve resources.

Which state model works best for you?

Value Entities give you the benefits of the Entity pattern in general: scalable, long-lived, addressable behaviors. Because Event Sourced Entities store state as a sequence of state-changing events, they offer extra benefits such as auditing, temporal queries to reconstruct historical state, and so on.

You may find Value Entities more straightforward to implement because you do not have to think about events. With Value Entities, you also have traditional database-like consistency. Event Sourced Entities are eventually consistent.

Both state models relieve you of writing the plumbing code normally required for data access.

Event storming

When designing Event Sourced Entities, you will want to use techniques for architectures that support that style of isolation. A technique called Event-Storming, for instance, helps you identify the events that your system will need as first-class items.

Learn more about: