How should I architect my DB & API server for a turn based multiplayer iPhone board game? (thinking about nodejs, mongo, couch, etc)

I'm working on a turn based board game for iPhone and eventually Android. I'm using Appcelerator Titanium to develop it. My multiplayer design is similar to Words With Friends. Users take turns when ready, and then the opponent's game board is updated accordingly.

One of my needs is to have a messaging API which enables the 2 players' devices to update one another on the status of the game board after a move. Thinking of doing this with JSON and keeping a JSON object on the device which contains the location of all game board pieces at any given time. This is the object that will need to update on the local device and then send a change to the opponent's device after a move is made.

I've done APIs in the past for mobile platforms and to do so I've used PHP with MySQL and sent JSON back and forth between the API server and the mobile device. Works just dandy for low concurrent users, and generally non-massive apps. Here's to hoping this one will get massive ;)

So now, instead of a general httpd server and the like, I'm starting to think about persistent sockets and if they're needed or not for my new game. I'm also thinking that it might be smart to forgo the big LAMP stack, and for scalability and maybe ease of development, to lean more towards a data flow of something like Mongo/Couch -> node.js -> iPhone. I'll be honest, it would be my first foray into a non-sql db and node.js as well.

Interested to hear others' takes and experiences on this, more options/thoughts, and whether I am thinking about it the right way, or just creating headaches for myself.

First of all, Nodejs is awesome for writing reverse TCP proxies to NoSQL databases. You could let all the standard commands pass through but alter/extend their APIs with your own magic, e.g. making MongoDB speak HTTP or CouchDB speak a binary protocol over sockets.

When it comes to choosing a NoSQL solution for storing board game pieces and monitoring for player moves I think either Redis and CouchDB are the best candidates.

1. CouchDB. It's fast, reliable, and can handle a lot of concurrent HTTP connections. It's probably the best option because unlike Redis it can broadcast a message when a document changes. The continous changes API makes it super simple for you to have each player's app monitor for changes to their board. The request might look like:
   
   

   curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000

   
   Each client will receive a JSON object per line in the response anytime a pertinent document is changed. (And a blank newline every 1000ms as a sort of keepalive.)
   
   
2. Redis. It uses a simple line-based protocol (like MemcacheD++) to talk over a socket and allows you to store Lists, Sets, Hashes with arbitrary--even binary--values. It's very fast because everything happens in memory but is persisted to disk asynchronously. But most of all you should evaluate it because it already has PubSub notifications baked in. Note that you'll have to explicitly publish move notifications over a channel the players share because Redis won't automatically publish when a key/value changes.

Since MongoDB does not have a mechanism for observing changes as-they-happen or doing pubsub I don't consider it a good option, though with extra effort you could make it work.

So to conclude, you may be able to replace "the big LAMP stack" with CouchDB alone, Redis alone, or either one placed behind a node app for filtering/extending the APIs they already provide into something that fits your game.

Best of luck!