Location of state within stateful microservices

Question

With Azure Service Fabric I can build microservice applications using stateful services. To build a microservice application, Service Fabric offers two high-level frameworks for building services: the Reliable Actors APIs and the Reliable Services APIs.

I want to use stateful reliable actors as services. Inside the actor I can keep any state. My question is, what is the maximum size of the "state data" to hold in an actor instance? Where is the state kept? In RAM? When I deactivate an actor, what happens with the states?

For example my actor represents an iot device. So the actor collects measured values in a list. What is the best choice to handle the state? How often should I flush the data to a persitent storage? How long can the service collect the data in a state until getting performance issues or other problems?

Answer 1

State is kept both in RAM and on local disk. Service Fabric handles replication of the data across multiple nodes in the cluster on your behalf to ensure the data is durable and highly-available. You don't need to flush data to external storage to make it durable, but you might consider doing so if you have vast amounts of cold data you want to offload for offline analytics.

When an actor is deactivated it is removed from the active actor list and its state is removed from RAM, but it continues to be persisted to disk. When a deactivated actor is re-activated at a later time, its state is re-hydrated in RAM from disk.

Theoretically there's no maximum state size but there are configurable size limits in the replicated store and transport used by actors. The general concept of actors leans toward a large number of small things, although it's up to you to find the right balance to meet your requirements.

Given that, there are two models for stateful actors:

StatefulActor<T> - in this model, you have a single state object of any type T. This is best used for state whose size does not grow over time because the entire state object is replicated and stored at the end of an actor method. If you continuously add to the state (like a growing list, for example) then you end up with the same performance problems as Shlemiel the painter.

StatefulActor - in this model your state is kept in a key-value data structure where you explicitly save state. This is better suited for state that grows because you aren't replicating all the state each time.