Stateful Services with Service Fabric

If the state is residing where the actual service is running then that service is called a Stateful service.

In a distributed environment having efficient and reliable state management system is a challenge,

According to CAP (Consistency Availability and Partition Tolerance) Theorem States that in a distributed System it is impossible to provide more than two guarantees of the three

1.  Consistency – Every read gets the latest write
2.      Availability – Every request receives a non-error response  without the guarantee that it is latest write '
3.  Partition Tolerance – System continues to work despite the unavailability of certain nodes (Network outage, down due to maintenance).

But this does not mean you cannot achieve good level of Consistency and Availability.

Let’s see how Service fabric state management system helps us get the maximum out of the two.

The Architecture and the important components associated with the Stateful Services in service fabric is below

·        As we know by now ICommunicationListener is designed to take request from the clients.

·        IStatefulUserServiceReplica has the implementation in StatefulService and the Service fabric runtime manages the lifecycle of Stateful Microservice through StatefulService.

·        The IReliableStateManager implementation gives you the State Manager using which you can handle all the actions related to State Providers (Reliable Collection).

·        The IReliableCollection implementation gives you the state providers which are used to save the states, currently there are 3 types of Reliable Collections(Reliable Dictionary , Reliable Queue , Reliable Concurrent Queue) , the Reliable collection implementation is Replicated , Persisted , Asynchronous and Transactional in nature  (More on this Later )

·        Transactional Replicator is responsible for replicating the state providers(reliable collections) to the secondary replica’s this step makes sure that the state data is reliable consistent and highly reliable and once the  replication is complete it calls into Logger

·        Logger is responsible to save the state changes on to the local disk using append only log files. This helps the states to be restored when a node crashes using the log files.

o   There are two types of logs

§  Shared Logs: They are saved under node level working directory for saving Transactional data.

§  Dedicated logs: They are replica-level logs saved under the service working directory.

The state information first is saved to the shared log and then is lazily transferred to dedicated logs in the background