Sure - I can speak to that a bit (there's a bit more information in an interview we did over at: http://blog.nodefly.com/post/49780591448/nodefly-buzz-atomic...)

We're currently running an all javascript (coffeescript) stack. In the backend we have a variety of node.js servers. We have the following "types" of servers:

- Metagame: handles our web api requests - Game: handles all the game logic, on the server. no client side game logic. Because we're all JS - client is effectively open-source. - Notification: routes messages and notifications to the users, utilizes 0mq between servers. - Matchmaker: takes in requests for game searches, keeps requests in memory, and finds matches. - Overseer: orchestrates where all the servers live. Want to know the address of a server? talk to the overseerer. Need to spin up a new game server? Overseerer. - League: Handles league management.

We currently have physical 6 servers (2 metagame, 2 game, 2 for the others). The metagame mixes web-sockets and standard web requests. The game server is web-socket only. These are the only two servers that talk to the clients. All other servers just network between themselves.

The Metagame, and Game server are fronted by nginx which acts as a reverse proxy, does ssl termination, caching policies, etc. All our assets (images, etc) are stored on Amazon Cloudfront, and cached forever. All filenames encode the MD5 signature of the file to ensure that we can cache everything forever, speeding up the clients.

We're currently using MongoDB to store all our game data. We use http://www.objectrocket.com/.

We were also accepted into the Rackspace (http://www.rackspace.com/) startup program which provides us a lot of free servers for a year. While we don't need all 6 servers right now, we can test out the infrastructure and launch this way, allowing us scale up easier. Free for a year was a good reason to move away from AWS - where we previously resided.

We went with nodejs - largely because of the "fun" factor. When we started we didn't have a ton of familiarity with it, but we wanted something different, and node had a lot of buzz at that time. While writing it in C, Java, or Erlang would of been more in our wheelhouse, we knew this was a hobby project and wanted to learn something new and enjoy ourself. It turned out to be a good choice, node is great. It performs well, and is a joy to work with. I've always felt that server side performance just needs to be good enough, you can optimize and optimize and optimize, but at the end of the day your stack needs to be architected such that it can run on 100s of computers at a time. You can only run with 1 server for so long, so creating something is scalable in hardware is more important then squeezing a single server for all it's worth. Node, combined my 0mq (for us) makes this a snap. My 2 cents anyhow.

Mongo was chosen for a similar reason. It has nice aspects to it, and is a great compliment to an all JS system. For us, we're not query heavy so it was a good choice. That said, as we add features, I can see partitioning our data into mongo data and more traditional RDBMS data. Mongo is good for certain classes of data, but you need to know what you're getting into. If you'd like me to talk to anything else, let me know.

user:	Shorrock
created:	November 24, 2011
karma:	12