Choosing a State Model

Cloudstate supports more than one model for handling your application’s state, and each model has certain advantages. For each service, you must select one of these models to use for a specific entity. In this section, we will describe the available models and their unique strengths.

Event-Sourcing

Event-sourcing is a Reactive technique for managing data in a distributed system. It 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 change. 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 of spinning up new services to handle load.

Event-sourcing systems might persist changes in a journal, or in an event log. 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.

Cloudstate Event Sourced Entities support event sourcing.

Conflict-Free Replicated Data Types

Often abbreviated as CRDT, a conflict-free (or convergent, or commutative) replicated data type is a special form of data structure that allows its information to be copied from one portion of a system to another (via events), but without ever generating a conflict, no matter what order the updates arrive in.

For example, a simple total is an example of a CRDT: If you are adding small integers together, it doesn’t matter in what order you get the additions, you’ll always end up with the same total if you get all the additions. This allows the additions to be distributed around to pieces of the system, with the guarantee those pieces will arrive at the same answer in the end.

Cloudstate Replicated Entities support a number of such CRDT data types, as described here.

Services that do not need durable state

You might have services that do not need durable state on the client side or on the server side. Services for the Web UI can be written using any framework you like, and you do not need to deploy them on Akka Serverless. On the server side, you can use data model Actions for stateless functions that you can deploy on Akka Serverless.

State model summary

Table 1. State Models
Name Description Strengths Notes

Event Sourced Entities
(Event Sourcing)

Entity state is built up from a series of durable deltas stored in an event journal

* Extremely flexible, built-in auditability, state can be rebuilt if errors in logic occur.
* At this time, do not support streaming.
* Support forwarding control and emitting effects to another entity.

Eventually consistent. See Event sourced Entities

Replicated Entities
(CRDTs)

Entity state is replicated to all nodes in the cluster, extremely performant reads

* Only a limited number of data structures can be used, not durable across restarts
* Support streaming.
* Support forwarding control and emitting effects to another entity.

Eventually consistent. See Replicated Entities for more information.

Actions

Stateless functions

* Support forwarding control and emitting effects to another entity.

For services that do not need durable state on the server side.