So here is the basic plan of what is needed to get going. Like all plans this may change as we get going and learn more. The general components that are needed are:
A Website to display a users view of the achievements.
This will allow a user to view the available achievements, the achievements they have earned, and hopefully the progress towards specific achievements.
A console application simulating activity that will generate achievements.
This console application will simulate the activity that will trigger achievement progression. Ideally there would be another service that would watch a service bus for these events, since that is outside the scope of this blog series this console application will take the place of that service.
An API used to interact with the achievement engine.
This will be used by multiple components. The website will use the API to get information about a users achievements. A console application will use the API to trigger achievement events.
Actors for the individual achievement types.
This is where things get interesting. Each achievement type (Daily Goal, Daily Fuel, Total Fuel, Streaks, and Date based) will have its own actor. Each user will have their own instance of each of the achievement actors. For example, given two separate users the following instances of the achievement actors would be instantiated.
| User1:DailyGoal | User2:DailyGoal |
| User1:DailyFuel | User2:DailyFuel |
| User1:TotalFuel | User2:TotalFuel |
| User1:Streaks | User2:Streaks |
| User1:DateBased | User2:DateBased |
Actor for each user.
This actor will maintain the state of the achievements for the user. This will stop the need to query each of the achievement types for the status of that specific achievement.
Why Actors?
The reason to use actors will make more sense as we write the code but for more information please go here: Reliable Actors Introduction. Pay close attention to the following sections:
- Actor Lifetime
- Distribution and Failover
- Concurrency
The concurrency section is the most important one to check out. The volume of events that could pass through this achievement engine could easily create a huge concurrency issue in the system. The actor pattern solves this for the most part.
Another nice thing about using the actor pattern here is the actor itself is very specific. For example when we build the Streaks achievement actor we will only need to concentrate on what that specific actor needs to do.
