CODEWITHSUNDEEP
c#.netmicroservicesazure-service-fabric
CPA
CPA

Reputation: 3053

Service Fabric Service vs. Service Fabric Actors for user representation

In my application users can post events on a map. The entry point of the application is a stateless web api service. For representing the users internally, I want to have an user service. When should I use Reliable Stateful Actors and when Reliable Stateful Services to store the profile data and the posted events of each user?

When a client creates a new user at the frontend, the actor or service should create a new user internally. And every time the user is logged in, the web api service should forward all user interactions to the internally representation of the user (Actor or Service). E.g. the user post a new event, the web api service find the user and forward the posted event to him. Because the posted event is public, I also want to have an reliable stateful event service. After storing the posted event inside the user, the user service should forward the event to the event service.

For example:

Client/User --> WebApiService --> UserService/UserActor --> EventService

And when a user want to see all the public events on a map the should be something like this: 

Client/User <-- WebApiService <-- EventService

Because the events have a geo reference, I want to partition the EventService based on geocodes or something like that.

Which programming model (actor and/or service) should I prefer for such an application and why?

Upvotes: 2

Views: 1727

Answers (1)

Vaclav Turecek
Vaclav Turecek

Reputation: 9050

Either way could work for this scenario but it doesn't sound like you have a need for features of the Actor pattern here, so I would suggest starting with a Reliable Service and storing the users in a Reliable Dictionary. Keep in mind that Actors are a specific pattern implemented on top of Reliable Services so in some ways you'll be limited to the constraints of that pattern, which might be a problem later on if not planned for carefully. For example, running a query over a set of actors doesn't work very well, so if you decide at some point later on you need to run a query over your user base, you'll be much better off if you use a Reliable Dictionary where it's easy to do queries.

For your event service, yes you can certainly partition by geo-coordinate. One way I've done this in the past is to convert geo-coordinates to quadkeys, which are a convenient way to represent 2D spatial data in a one-dimensional key. However, keep in mind you may get local hotspots which could cause some clustering in your partitions (are most of your users centered around major cities? If so, those paritions will have more data than others).

Upvotes: 2

Related Questions