We recently launched Village Chief, a Facebook game in which you take on the role of a local village chief with the aim of growing your community into a thriving settlement.
The project was designed from the ground up to be highly scalable – Facebook cames can go viral very quickly so you need a system which can scale up very quickly if your game suddenly becomes very popular, or you risk losing out on huge amounts of market capitalisation.
First off, it’s written in Ruby. Ruby is a cool scripting language that is similar to Python and it’s popular web framework Ruby on Rails has received a lot of praise being the framework that Twitter and 37signal’s suite (Basecamp, Highrise, etc) are written in. It’s a very forgiving language, even compared to PHP, so if you like your static typing consider Scala instead, but for rapid web development, Ruby is a gem.
Despite the popularity of the Rails framework, I was looking for something a little more lightweight, so Village Chief is built using Sinatra. The documentation is a little underdeveloped but is never the less sufficient to get buy and lets you get a web application up and running nice and fast.
Ruby also includes a great module system called Ruby Gems (spot the earlier pun now 😉 ), a system similar to PHP’s PECL. The game makes heavy use of these – for example, using Koala to interact with Facebook and Dalli to handle our caching.
For a data source, it made sense to use a NoSQL solution. I originally settled on Apache Cassandra. It doesn’t have the flexibility or functionally of Mongo but it terms of raw speed it’s hard to beat and scales onto multiple servers with eventual consistency beautifully.
When it came to deployment, I decided to go with Amazon AWS’s DynamoDB instead. I’ll discuss more about why this was later but this meant rewriting the database interaction. This was easy to do thanks to our database abstraction layer and allowed us to continue using Cassandra for our testing systems while rolling out the production environment on DynamoDB.
Some data was also rolled out using SQLite. This was used for data such as the product catalogue which doesn’t contain user data – just things you can buy. Keeping it in an SQLite database allows us get quick access while still being able to query against the records – and importantly, allows us to version control our product catalogue.
To keep the database load down, some of the sorting was moved into the web server layer instead. On top of this we built a caching system using Memcache to save a lot of the data in memory, thus making things much faster.
When it came to deployment, I decided that Amazon’s EC2 cloud. You can start up a new server in under a minute, which is fantastic for scalability. Thanks to Amazon’s Elastic IPs, you can maintain a set of public IPs and map them to any one of your EC2 servers.
The servers are based on the latest Ubuntu release and to make sure that they are delivering content at top speed, I choose to go with the nginx web server rather than Apache, which works in conjunction with Passenger to provide the platform.
One limitation of EC2 is that you either have to allocate EBS (Elastic Block Storage) which adds additional cost, or use the ephemeral storage which you lose every time you turn the box off. The solution? Put everything into an external database so that we can switch boxes on and off without a problem – hence the decision to use DynamoDB rather than running Cassandra on the servers.
Code is then deployed using Capistrano which goes onto each of the boxes and performs a structed deployment that you can easily roll back, pulling the code direct from our Git repository.
That is a whistle-stop tour of the technologies used in Village Chief. If you have any questions about any of them, feel free to post a comment.