View on GitHub

adr

Journal of Architectural Decision Records made for the project

Actors are Stateless

Status

Accepted

Context and Problem Statement

Many actor frameworks have built-in, language-idiomatic support for state. Actors can maintain private state or use special APIs to maintain distributed state. Should our actors be stateless or stateful?

Decision Drivers

Considered Options

Decision Outcome

Chosen option: “stateles actors”, because we feel that stateless actors are the best option to provide the flexibility, ease of use, and scalability while adding the least amount of complexity and “new primitives” to the underlying framework. For more details, see below.

Positive Consequences

Negative Consequences

Pros and Cons of the Options

Stateless Actors

The term “stateless”, as usual, needs to be clarified within this context. State in the case of an actor defined within a WebAssembly module means values that exist in that module’s linear memory. By saying “stateless”, what we’re actually saying is that the host runtime provides no guarantees that any data in linear memory will remain unaltered between function calls, or will be restored when an actor is restarted.

Stateless actors do not rely on values to remain in their linear memory, and they must rely upon bound capability providers to access any persistent state.

Even Dapr, which claims to have stateful actors, is really doing the same thing our runtime does–exposing a service that communicates with external state 1 .

Stateful Actors

Stateful actors in this context refer to actors that operate on state as though it is guaranteed to remain available across instance restarts of a given actor. This comes with the assumption that the substrate or system in which the actor is running is deeply (e.g tightly coupled) aware of, managing, and supplying all state for all actors.

Whether it’s an illusion to the developer or not, state does not appear to be external, and is often manipulated using basic programming language idioms.

An example of the kind of complexity sprawl we did not want to take on for a lightweight lattice can be found in Akka2 persistence.

Links, references, and footnotes