To support scalability and reliability, Service Fabric supports setting up multiple instances of service and supports partitioning a service. Let's see what this concept means for stateless and stateful services.

Stateless services do not store any data locally. When you add a new stateless service in your Service Fabric application, you will find that a configuration is automatically created in ApplicationManifest.xml to configure the service to use SingletonPartition:

    <Service Name="Stateless1"> 
      <StatelessService ServiceTypeName="Stateless1Type" 
         InstanceCount="[Stateless1_InstanceCount]"> 
        <SingletonPartition /> 
      </StatelessService> 
    </Service>   

SingletonPartition means that, number of partitions is one, which means that there is a single instance of state. If you set the value of [Stateless1_InstanceCount] parameter to 2, you will have two instances of the service running on different nodes. If you put a breakpoint in the RunAsymc() method of Stateless1 class, you would find that it will be invoked twice, once for each node on which it is deployed.

Due to absence of state data, other partitioning schemes do not make sense for stateless services. To explore the other partitioning schemes, let's add a stateful service to the project. After the template unfolds, you would find the following configuration in the application manifest file:

    <Service Name="Stateful1"> 
      <StatefulService ServiceTypeName="Stateful1Type" TargetReplicaSetSize="[Stateful1_TargetReplicaSetSize]" MinReplicaSetSize="[Stateful1_MinReplicaSetSize]"> 
        <UniformInt64Partition PartitionCount="[Stateful1_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" /> 
      </StatefulService> 
    </Service> 

You will notice that instance count is no longer present in the configuration and is replaced with replica count. A replica is a copy of code and state data of a service. Let's simplify the preceding configuration to make it easier to understand:

    <Service Name="Stateful1"> 
      <StatefulService ServiceTypeName="Stateful1Type" 
         TargetReplicaSetSize="3" MinReplicaSetSize="2"> 
        <UniformInt64Partition PartitionCount="2" LowKey="1" 
           HighKey="10" /> 
      </StatefulService> 
    </Service> 

By default, your stateful services uses uniform partitioning scheme named UniformInt64Partition. This partitioning scheme uniformly distributes a continuous key range to the number of partitions that you specify. Using the preceding configuration, the state data will be partitioned in two parts, one partition will serve keys ranging from 1 to 5 and the other partition will serve keys ranging from 6 to 10. Each of these partitions will have a minimum of two replicas, which can expand up to three. If you deploy your application, you will find that six instances of your application will spin up, three replicas for each partition. However, if you put breakpoint in RunAsync () method, it will be hit only twice, once for each primary replica of a partition because the rest of the replicas won't be in active state.

Next, let's change the partitioning scheme to NamedPartition. Named partition scheme is useful in cases where the number of partitions are known in advance and remain static over time, for example partitioning an application by states in a country:

    <Service Name="Stateful1"> 
      <StatefulService ServiceTypeName="Stateful1Type" 
         TargetReplicaSetSize="3" MinReplicaSetSize="2"> 
        <NamedPartition> 
          <Partition Name="A" /> 
          <Partition Name="B" /> 
          <Partition Name="C" /> 
          <Partition Name="D" /> 
        </NamedPartition> 
      </StatefulService> 
    </Service> 

If you deploy the solution now, you will find that twelve instances of your application will get deployed, three for each partition. However, the breakpoint on the RunAsync method will only be hit four times, once for each primary replica of a partition.