CODEWITHSUNDEEP
architecturemicroservicesconsistencyazure-service-fabric
Code Monkey
Code Monkey

Reputation: 310

Consistency with partitioned Service Fabric stateful service

Let's take a simple example. I have a stateful service that manages users. It has a reliable dictionary that maps UserID to some data, including User Name.

In this service's RegisterUser method, we want to check that the user name has not already been used. This is quite straightforward when the service is a singleton, but when it's partitioned we end up with several problems:

  1. We have to ask all partitions if the user already exists. We could possibly introduce another singleton service that maps user name to user id to overcome this problem.
  2. There's a race condition. Two users could try to register the name user name at the same time. It's possible that both users could succeed.

I'm looking for general advice for possible ways to deal with situations such as this. I can imagine that this sort of problem would occur regularly with partitioned data.

Upvotes: 0

Views: 697

Answers (4)

Biju P. K
Biju P. K

Reputation: 1

Reliable collection in SF can be used for concurrent transactions with consistency is guaranteed by Service fabric. You will not face any issue due to partition if you are using the same dictiornary across your partitions. Problem becomes complex when you need to update two disctionries simulataneously and you have depended data in each dictionary. In that case you can use patterns like "Saga" pattern or "Twophase commit" patterns.

Please refer https://learn.microsoft.com/en-gb/azure/service-fabric/service-fabric-reliable-services-reliable-collections#persistence-model for more info: Reliable Collections provide strong consistency guarantees out of the box to make reasoning about application state easier. Strong consistency is achieved by ensuring transaction commits finish only after the entire transaction has been logged on a majority quorum of replicas, including the primary. To achieve weaker consistency, applications can acknowledge back to the client/requester before the asynchronous commit returns.

Reliable Dictionary: Represents a replicated, transactional, and asynchronous collection of key/value pairs. Similar to ConcurrentDictionary, both the key and the value can be of any type.

Upvotes: 0

itaysk
itaysk

Reputation: 6236

Since none of the existing answers address your questions directly (however valid suggestions), I'll answer your original questions for the record:

  1. Usually you would use some kind deterministic partitioning scheme, for example range partitioning - so for example if you need to search for user 'foo' you would search the F partition (or the E-G partition) and not every partition.
  2. SF reliable collections use transactions which might be able to protect you from the side effects of race conditions. Read this for more details: https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-services-reliable-collections/#persistence-model

Your title talks about consistency level - all operations in Service Fabric are strongly consistent, meaning a write will be committed in all replicas before acked.

Upvotes: 1

alltej
alltej

Reputation: 7285

Since the client app in this case require a response right away that dont depend on other state from actor/service, I think stateless service will be better choice. The state that you depend on is data from the external store like database.

Upvotes: 0

Rob Conklin
Rob Conklin

Reputation: 9446

This is usually resolved with an external data store that is atomic in nature. Use a transactional data store like a SQL database to store user names/ids. This will allow you to do things like create unique constraints to enforce the uniqueness of these user names.

Upvotes: 1

Related Questions