Web services or shared database for (game) server communication?

Posted by jaaronfarr on Stack Overflow See other posts from Stack Overflow or by jaaronfarr
Published on 2010-05-14T07:40:25Z Indexed on 2010/05/14 7:44 UTC
Read the original article Hit count: 185

We have 2 server clusters: the first is made up of typical web applications backed by SQL databases. The second are highly optimized multiplayer game servers which keep all data in memory. Both clusters communicate with clients via HTTP (Ajax with JSON). There are a few cases in which we need to share data between the two server types, for example, reporting back and storing the results of a game (should ultimately end up in the database).

We're considering several approaches for inter-server communication:

  • Just share the MySQL databases between clusters (introduce SQL to the game servers)
  • Sharing data in a distributed key-value store like Memcache, Redis, etc.
  • Use an RPC technology like Google ProtoBufs or Apache Thrift
  • Using RESTful web services (the game server would POST back to the web servers, for example)

At the moment, we're leaning towards web services or just sharing the database. Sharing the database seems easy, but we're concerned this adds extra memory and a new dependency into the game servers. Web services provide good separation of concerns and fit with the existing Ajax we use, but add complexity, overhead and many more ways for communication to fail.

Are there any other good reasons not to use one or the other approach? Which would be easier to scale?

© Stack Overflow or respective owner

Related posts about scalability

Related posts about web-services