Amazon DynamoDB: Gaming use cases and design patterns

Gaming companies use Amazon DynamoDB in all parts of game platforms, including game state, player data, session history, and leaderboards. The main benefits that these companies get from DynamoDB are its ability to scale reliably to millions of concurrent users and requests while ensuring consistently low latency—measured in single-digit milliseconds. In addition, as a fully managed service, DynamoDB has no operational overhead. Game developers can focus on developing their games instead of managing databases. Also, as game makers are looking to expand from a single AWS Region to multiple Regions, they can rely on DynamoDB global tables for multiregion, active-active data replication.

In this blog post, I detail some of the most common use cases and design patterns of gaming companies that use DynamoDB.

Terminology used in this post

In this post, I use the following data modeling terminology:

• 1:1 modeling: One-to-one relationship modeling using a partition key as the primary key.
• 1:M modeling: One-to-many relationship modeling using a partition key and a sort key as the primary key.
• N:M modeling: Many-to-many relationship modeling using a partition key and a sort key as the primary key with a table and a global secondary index.

Gaming use cases and design patterns

Use case: Game state and player data store

Using DynamoDB to store player game state and other player data allows game companies to accommodate high numbers of concurrent players while maintaining millisecond access latency. As an example, consider Electronic Arts (EA), a large video game company with more than 300 million registered players around the world. For EA, high concurrency can mean more than 100,000 requests per second and millions of daily active users. By migrating to DynamoDB, EA realized a 90 percent cost reduction over the old database, a MySQL cluster. EA uses DynamoDB to store game state, user data, and game inventory data in multiple tables. EA uses the user ID as the partition key and primary key (a 1:1 modeling pattern).

PennyPop, the maker of Battle Camp, a massively multiplayer online role-playing game, used DynamoDB to launch Battle Camp with only a few requests per minute and scaled to more than 80,000 requests per second. Because DynamoDB is a fully managed service, it allows PennyPop’s small development team to focus on game development and not on operations. Also, by using DynamoDB, PennyPop has saved at least 50 percent per year when compared to hosting and sharding their MySQL database. PennyPop would have needed to double its operations staff from three to six server engineers to run the same environment on premises.

Design patterns: To store data in DynamoDB, gaming companies partition game state and other player data using player ID, and use the key-value access pattern (1:1 modeling). In cases when more fine-grained access is called for, these companies use a sort key (1:M modeling). This allows them to access and update different properties or subsets of a player’s dataset separately. This way, they don’t have to retrieve an entire dataset. In this approach, multiple items that store different properties can be updated transactionally by using the DynamoDB transactional API. Some companies compress user data to reduce cost. PennyPop, for example, uses gzip to compress player data and store it as a base64 string, reducing the player data to 10 percent of its original size.

Use case: Player session history data store

Game makers store session history and other time-oriented data in DynamoDB for fast lookup by player, date, and time. For example, Riot Games, which serves international players who create terabytes of data daily, stores player session history in DynamoDB. This allows its Player Support team to look up all the information for a given player quickly, such as all the player’s in-game purchases and last login time. This data was stored formerly in Vertica, which is good for analytics but not for single-key lookup. Lookups often took minutes. Riot Games decided to use DynamoDB to improve lookup performance, and copied all data from Vertica to DynamoDB, creating a materialized view of all user data and history in DynamoDB for fast lookups. Using DynamoDB helped reduce the lookup time from minutes to less than one second.

Design patterns: To store player session history and other time-oriented data in DynamoDB, gaming companies usually use the player ID as the partition key and the date and time, such as last login, as the sort key (1:M modeling). This schema allows these companies to access each player’s data efficiently by using the player ID and date and time. Queries can be easily tailored to select a single record for a specific date and time, or a set of records for a given range of date and time.

Use case: Leaderboard

Game makers can support simple leaderboards easily by using DynamoDB. One such use case is the ability to display top scores for a game. If a gaming company already stores players’ game state in DynamoDB, including players’ top scores, the ability to get top scores can be implemented by using a global secondary index.

Design patterns: With a table partitioned by player ID that stores players’ game state, including the top score as an attribute, a leaderboard can be implemented with a global secondary index. The index would use the game ID or name as the partition key, and the top-score attribute as the sort key (N:M modeling). This is described in the Global Secondary Indexes section of the DynamoDB Developer Guide.

Summary

In this post, I described some of the most common DynamoDB use cases and design patterns for gaming companies. With options for strong and eventual consistency, support for multi-item ACID transactions, atomic counters, and in-memory caching with DynamoDB Accelerator (DAX), DynamoDB can satisfy many requirements commonly found in gaming applications.

For more in-depth information about gaming design patterns on AWS, see Introduction to Scalable Gaming Patterns on AWS. Also, for additional resources about developing games on AWS, see Amazon Game Tech. Submit comments below, or start a new thread on the DynamoDB forum.

About the author

Edin Zulich is a senior NoSQL specialist solutions architect at AWS who helps customers in all industries design scalable and cost-effective solutions to challenging data management problems. Edin has been with AWS since 2016, and he has worked on and with distributed data technologies since 2005.

This blog post is the first in a series of industry-vertical posts. The second post is Amazon DynamoDB: Ad tech use cases and design patterns.