AWS for Games Blog
Rethinking Game Leaderboards with Amazon MemoryDB for Redis
As multiplayer games continue to grow in popularity, leaderboards are becoming an essential tool for developers to increase gameplay between users. The overall core of leaderboards has never changed and the technology underneath them has been discussed by many as there are a few different ways to achieve the same goal. In this post, we will introduce Amazon MemoryDB for Redis as a great candidate for a leaderboard backend by presenting how its durability eases management and opens up a path to detangle the main service while migrating to a microservices architecture.
Background
There are many challenges found within game dev communities for increasing durability of leaderboard data. A common approach for solving this complicated problem is using a combination of Amazon ElastiCache for Redis and a persistent database layer.
One method is to achieve atomicity of the leaderboard scores and developers often wrap Redis API calls with persistent database transactions. For example, if you utilize Amazon Aurora as a primary database and then use a MySQL transaction to wrap the Redis updates. This approach is laborious, as you have to make sure all API calls that need to update Redis are wrapped with transactions.
Another approach is operating under eventual consistency. With Amazon DynamoDB, developers have the ability to advance DynamoDB Streams to capture changes in leaderboard scores and eventually update data in Redis. Since the operation is not synced, the game client needs to afford the delay of score updates, though games are generally tolerant of eventual consistency.
The third way is having a cron job running at a certain frequency. Developers can easily set scheduled jobs with Amazon EventBridge, and scan the persistent database to update Redis or vice versa. Both the second and the third methods sync data over the course of time, but this introduces internal service rules to verify that clients are reading scores from consistent sources. Although with the first approach data is synced over two data storages, you may be required to have transactions for reading as well.
A persistent layer regularly preserves other users data that are user names, skills, avatars and so on. This also drives the idea of composing user scores at the same location. Even though this process is indeed ordinary and may work well with modest games, database decomposition will be required for scalable backends with millions of players.
Introducing Amazon MemoryDB for Redis
Amazon MemoryDB for Redis is a fully managed, Redis-compatible, in-memory database service that also has higher durability. MemoryDB stores data with in-memory storage that uses a Multi-AZ transactional log to maintain its durability. This service also introduces a robust ability to recover from disasters while sustaining and inheriting Redis’ ultra-fast performance. Consequently, this unique behavior suits perfectly to leaderboards in games and eliminates requirement of transactional integrity over multiple data storages.
Not only is MemoryDB fast and reliable, but it is also scalable. Game developers can scale a MemoryDB cluster horizontally by adding or removing nodes, or vertically by selecting node types. These scaling operations are completely transparent from the callers, in other words, adding more leaderboards will never require maintenance to the live game.
Using Amazon MemoryDB
With Amazon MemoryDB for Redis, you can store all of your leaderboard data independently and you do not need to store the same score data into your primary database. For example, with Amazon Aurora, any extra transaction is required and leaderboard operations are not completely decoupled from other player stats operations. Adding new features into the game will be much simpler than modeling data in two places and synchronizing two data sources. If the game requires metadata for leaderboards, you could simply use MemoryDB to store the metadata as well.
Leaderboards as a microservice
There are a number of different types of leaderboards that we see in games, with seasonal leaderboards, weekly leaderboards, guild leaderboards, or life-time leaderboards. Most of them serve different values but fundamentally they are all very similar. In fact, you can take out all of the unique attributes of the individual leaderboards and make one generic service combination to manage all kinds of leaderboards. You can create a scalable leaderboard service with Amazon ECS or AWS Lambda, by combining it with MemoryDB. You will then have a complete leaderboard microservice that scales separately from your main game server. Furthermore, the same exact combination can also support multiple games by adding namespaces or prefixing keys. With this architecture, game clients will be retrieving their scores from a consistent location, a feature from MemoryDB. You can find a great sample application for microservices using MemoryDB that teaches best practices and a detailed explanation for implementation below.
Conclusion
Although maintaining a database and performance is not an easy process, services like Amazon MemoryDB for Redis help with leaderboard requirements in games. Game developers are able to not sacrifice any architectural advantages and can focus on what is valued most to make their game best.
 |
Authored by: Takahiro Ishii (@takahiroishii_)| Game DevRel, AWS Game Tech |