Understand the Problem
In this chapter, we are going to walk through the challenge of designing a leaderboard for an online mobile game.
What is a leaderboard? Leaderboards are common in gaming and elsewhere to show who is leading a particular tournament or competition. Users are assigned points for completing tasks or challenges, and whoever has the most points is at the top of the leaderboard. Figure 1 shows an example of a mobile game leaderboard. The leaderboard shows the ranking of the leading competitors and also displays the position of the user on it.
Step 1 – Understand the problem and establish design scope
Leaderboards can be pretty straightforward, but there are a number of different matters that can add complexity. We should clarify the requirements.
How is the score calculated for the leaderboard?
The user gets a point when they win a match. We can go with a simple point system in which each user has a score associated with them. Each time the user wins a match, we should add a point to their total score.
Are all players included in the leaderboard?
Yes.
Is there a time segment associated with the leaderboard?
Each month, a new tournament kicks off which starts a new leaderboard.
Can we assume we only care about the top 10 users?
We want to display the top 10 users as well as the position of a specific user on the leaderboard. If time allows, let’s also discuss how to return users who are four places above and below a specific user.
How many users are in a tournament?
Average of 5 million daily active users (DAU) and 25 million monthly active users (MAU).
How many matches are played on average during a tournament?
Each player plays 10 matches per day on average.
How do we determine the rank if two players have the same score?
In this case, their ranks are the same. If time allows, we can talk about ways to break ties.
Does the leaderboard need to be real-time?
Yes, we want to present real-time results, or as close as possible. It is not okay to present a batched history of results.
Now that we’ve gathered all the requirements, let’s list the functional requirements.
-
Display top 10 players on the leaderboard.
-
Show a user’s specific rank.
-
Display players who are four places above and below the desired user (bonus).
Other than clarifying functional requirements, it’s important to understand non-functional requirements.
Non-functional requirements
-
Real-time update on scores.
-
Score update is reflected on the leaderboard in real-time.
-
General scalability, availability, and reliability requirements.
Back-of-the-envelope estimation
Let’s take a look at some back-of-the-envelope calculations to determine the potential scale and challenges our solution will need to address.
With 5 million DAU, if the game had an even distribution of players during a 24-hour period, we would have an average of 50 users per second (5,000,000 DAU / seconds = ~50). However, we know that usages most likely aren’t evenly distributed, and potentially there are peaks during evenings when many people across different time zones have time to play. To account for this, we could assume that peak load would be 5 times the average. Therefore we’d want to allow for a peak load of 250 users per second.
QPS for users scoring a point: if a user plays 10 games per day on average, the QPS for users scoring a point is: 50 * 10 = ~500. Peak QPS is 5x of the average: 500 * 5 = 2,500.
QPS for fetching the top 10 leaderboard: assume a user opens the game once a day and the top 10 leaderboard is loaded only when a user first opens the game. The QPS for this is around 50.
Finished reading?
Mark it complete to track your progress.