Scaling Your Social Games to Handle Popularity

Dr Robert Zubek of Zynga gave a fascinating talk, “Engineering Scalable Social Games,” at GDC 2010 Game Developers Conference about how Zynga has scaled up their computing resources to handle an increase number of players as well as increased usage. While the talk was fairly technical, here is the gist.

The primary problem: Social games by their very nature will attract increasingingly more players, and your servers have to be able to cope. A few reasons for growth:

  • Users will brag about their accomplishments, say on their Facebook Wall.
  • Their friends might follow suit and play, then do the same thing.
  • Friends of a friend (FoaFs) are the next layer in the viral loop.

If your game does go viral, thanks to social networks, your servers have to scale, else you’ll obviously have a lot of upset users. Zynga’s own games have 65M DAU (Daily Active Users) and 225M MAU (Monthly Active Users). FarmVille grew to 25M DAUs over only five months. To cope with that kind of usage, companies need to have the server infrastructure as well as software than can grow to scale.

So, how do you scale for games that become popular? Zubek looked at two areas: (1) Game architectures and (2) Scaling solutions. Let’s look at some of the options for each, in a nutshell.

Game Architectures

Game architectures are the combination of server and client used. While there are supposedly two types of each, in combination there are only three game architectures, according to Zubek:

  1. Web server stack over HTML client.
  2. Web server stack over Flash client
  3. Web + MMO server stack over Flash client.

Each type has its benefits and disadvantages, though these are beyond the scope of this post.

Scaling Solutions

The database and any caching sit over top of the game architecture. Databases can be “the first to fall over,” as Zubek put it. To scale, data needs to be sharded, aka partitioned. There are two ways to do this:

  1. Vertically – partition by table. This is easy to do but doesn’t scale well for increasing DAUs.
  2. Horizontally – partition by row.

There are also caching solutions that can be combined with database sharding.

Overall, there are two ways to scale solutions:

  1. Scale up. Scaling up requires moving to a larger box. Each time you scale up, you move to a bigger box, which at some point might become a problem.
  2. Scale out. Scaling out requires adding more boxes, which is typically easier to do than scaling up.

Zubek indicated that Zynga prefers scaling out over scaling up. He also said that the company is looking at “NoSQL” data tools such as Cassandra, though nothing is in production.

This is only a light look at a technical-dense subject. If you’re interested in learning more about developer issues such as those covered here, let us know in the comments. It’s also possible that Dr. Zubek’s presentation slides will be posted at GDC 2010‘s vault site.

Image credit: