Understanding when to use stateful services and when to rely on external persistence in Azure Service Fabric

Question

I\'m spending my evenings evaluating Azure Service Fabric as a replacement for our current WebApps/CloudServices stack, and feel a little bit unsure about how to decide when ser

Answer 1

I know this has been answered, but recently found myself in the same predicament with a CQRS/ES system and here's how I went about it:

1. Each Aggregate was an actor with only the current state stored in it.
2. On a command, the aggregate would effect a state change and raise an event.
3. Events themselves were stored in a DocDb.
4. On activation, AggregateActor instances read events from DocDb if available to recreate its state. This is obviously only performed once per actor activation. This took care of the case where an actor instance is migrated from one node to another.

Answer 2

One option that you have is to keep 'some' of the state in the actor (let's say what could be considered to be hot data that needs to be quickly available) and store everything else on a 'traditional' storage infrastructure such as SQL Azure, DocDB, .... It is difficult to have a general rule about too much local state but, maybe, it helps to think about hot vs. cold data. Reliable Actors also offer the ability to customize the StateProvider so you can also consider implementing a customized StateProvider (by implementing the IActorStateProvider) with the specific policies that you need to be more efficient with the requirements that you have in terms of amount of data, latency, reliability and so on (note: documentation is still very minimal on the StateProvider interface but we can publish some sample code if this is something you want to pursue).

About the anti-patterns: the note is more about implementing transactions across multiple actors. Reliable Actors provides full guarantee on reliability of the data within the boundaries of an actor. Because of the distributed and loosly coupled nature of the Actor model, implementing transactions that involve multiple actors is not a trivial task. If 'distributed' transactions is a strong requirement, the Reliable Services programming model is probably a better fit.

Answer 3

To answer @Trond's sedcondary question which is, "What does, 'if we do not implement the optional persistance' indicate here?"

An actor is always a stateful service, and its state can be configured, using an attribute on the actor class, to operate in one of three modes:

1. Persisted. The state is replicated to all replica instances, and it also written to disk. This the state is maintained even if all replicas are shut down.
2. Volatile. The state is replicated to all replica instances, in memory only. This means as long as one replica instance is alive the state is maintained. But when all replicas are shut down the state is lost and cannot be recovered after they are restarted.
3. No persistence. The state is not replicated to other replica instances, nor to disk. This provides the least state protection.

A full discussion of the topic can be found in the Microsoft documentation