For Devsisters, Cookie Run: Kingdom has been a particularly tasty success. The game has amassed more than ten million downloads, and handles hundreds of thousands of concurrent users. At peak traffic hours, it is sometimes processing 60,000 transactions per second. In this blog we’ll get into the architecture that supports a viral video game platform. But first…
What is Devsisters?
Devsisters, founded in 2007, is an international gaming company headquartered in South Korea. Cookie Run: Kingdom, the latest game they built, is a collectible RBG with a city-builder hybrid. They have two other games (Cookie Run: Oven Break and Cookie Run: Puzzle) and three more games coming soon.
The breakaway success of Cookie Run: Kingdom generated far heavier transactional workloads than they had originally anticipated. Cookie Run: Kingdom might never have reached this level of success were it not for one critical decision made early in the game’s development process.
A team of engineers from Devsisters recently told the story of their viral success and the challenges those serges of traffic created for their architecture. The Devsisters presentation slides, transcript and video are all available.
Here is the video of their presentation titled: Uptime as a core requirement for online games
Preparing for Success by Architecting for Scale
Prior to Cookie Run: Kingdom, Devsisters had released quite a few games based on its Cookie Run IP, generally using Couchbase and Aurora MySQL to power their databases. But early in the development of Cookie Run: Kingdom, the Devsisters team realized that continuing with Couchbase would be difficult.
Because of Couchbase’s document size limitations, Devsisters had been forced to implement in-game transactions at the application layer in previous games. Cookie Run: Kingdom, which tracks a wide variety of data points and includes an in-game trading system, would need something more robust.
RELATED
What is a database hotspot, and how do you fix it?
The Devsisters team was already familiar with CockroachDB, so as production of Cookie Run: Kingdom began to ramp up, they benchmarked it against other options, including Aurora and DynamoDB. CockroachDB won out because it offered the best performance for the price, and because the Devsisters team saw that they would be able to scale horizontally quickly and smoothly.
That decision proved to be critically important. Cookie Run: Kingdom was released and quickly shot up the app store charts. Its success meant that Devsisters needed to scale the database powering the game much more quickly than they had anticipated. Even with the game generating six times the workload Devsisters anticipated, CockroachDB has made it easy for them to keep up.
Had they chosen a different database, things would not have gone as smoothly. “Looking back, it would have been impossible to scale this game on MySQL or Aurora,” says Sungyoon Jeong of the Devsisters DevOps team.
CockroachDB’s high availability has also proved important, since scaling onto more and more nodes has increased the probability that at least one node will fail. That hasn’t been a problem, Jeong says, because CockroachDB “survives these failures very smoothly.”
The success of Cookie Run: Kingdom stems first and foremost from Devsisters’ hard work in creating a mobile game that’s fun, exciting, and deep enough to keep players coming back.
But the fact that they planned for scale from the outset and chose a cloud-native database that scales seamlessly has also played a huge role. If the game’s database had stuttered or crashed under the unexpected workload, it would have frustrated early players and probably slowed the game’s growth. But because they chose CockroachDB, Devsisters didn’t have to worry about the game’s quick success, because they know their database can scale to accommodate all the players eager to take a bite of Cookie Run: Kingdom.
Take a look at the diagram to see how devsisters deploys their CockroachDB clusters. And then learn more about how Devsisters deployed CockroachDB, and read their advice about getting a distributed SQL database up and running from the case study.
