Some background before I get on with my point: I read, but only very rarely agree with, Darrin West's blog Online Game Techniques. I think my biggest sticking point was one of his first posts, Replicated Computing (10k Archers) where he argued that synchronized simulation1 is a terrible idea, and a fool's errand. Since then, there has been more to disagree with, but sometimes I do agree and honestly, I feel bad for not talking about his posts more. I'd comment on his blog, but in the past authenticating sufficiently to be allowed to post comments has been an issue2.
Just the same I was pretty interested in his most recent post on Web tech for "game services" because that's been an interest of mine for a while (although in this precise context I've only touched upon the issue briefly). It started as a discussion of whether to be DB-centric or not, and wound up as a discussion of how to use web services as part of the game.
Touching on both subjects a bit, I think the right approach is to treat the database as an analysis-friendly blackbox data store. The game server writes data to the database (from which anything else is welcome to read), and reads it back later, but anything interacting with the game goes through the simulation engine. Some web services, like chat log search or character sheet inspection, would work just fine reading potentially-stale data from the database. Other potential web services, like an auction house or microtransaction system, should go directly to the simulation engines, do their transaction there, and let the engine manage storing the results.
The biggest reason for this is that relational databases don't have a good way of pushing data into the simulation, but they are designed to be excellent for having data pushed into them. This isn't as noticeable with web applications, because HTTP is stateless and so the natural pattern on the web is to gather implicit state from the database in response to a request, then process the request (probably pushing results and state changes back into the database), and to finally return a result. If your game server takes this model - and it's pretty much required for web-based games, so I'm not assuming you don't or can't - then using the database as the communication medium makes perfect sense.
However, as soon as you move away from that polling model, any web services that take that traditional (web) approach will screw the entire system up. The game server isn't notified of the changes; it doesn't poll the database for the changes; the changes are quickly overwritten. The next obvious step is to have the traditional web service take an extra step - notify the simulation engine that something has changed. What changed? Well, either the web service tells the simulation what changed, or the simulator has to figure it out; in the first case, there isn't any reason to complicate your transaction by also telling the database, and in the second case... well, I'll just say that in software development you should never imply a thing when you can state it outright.
In my opinion, then, you are left with two really good options, depending on your game: following the standard web model and relying on the database to be the primary communication and arbitration layer, or taking a simulation-centric model and relying on the database as a backing store only. A backing store that is reasonably amenable to data mining and analysis, yes, but not the arbiter of truth about game state - or even parts of game state.
1. Synchronized simulation is an approach to client/server synchronization where you minimize 'event' traffic to clients by sharing initial state, and events thereafter that one side or the other can't predict (mostly player actions - either yours or someone else's), and otherwise don't talk to each other. It is more common in peer-to-peer multi-player games (e.g., older RTS titles), and was also the model used in Dungeon Runners (which, in a previous incarnation, was an RTS). It has its issues, but I think it is a "solved problem" to greater extent than Darrin.
2. Last time I checked, "anonymous" and "name/URL" were not options for establishing your identity for comments; as I recall the options were "Blogspot account" and "OpenID account" - neither of which I have or want to bother creating. I feel bad for not starting discussion here, but then I would want to notify him that I'm talking about him, and the crazy downward spiral continues.
On the meat of the discussion, again, I suspect our differences are wrt definition. I do tend to exaggerate my position to spur a discussion (has it worked?). I'd love to drill down on statements that seem ludicrous or unsupported.
My position is that abiding by a single-writer (single-owner) paradigm gives you the best performance, best scale, and least complexity. That leads to my position on a simulation-centric architecture for core gameplay (combat, exploration, questing, interaction with other Entities,...). Adding game-services (non-core-gameplay) using web-tech should still adhere to single-writer. Meaning they work off a latent, read-only copy (as you suggest), disjoint data domains (Entities vs. Clans), or disjoint data elements (e.g. transfer ownership of entity records).
I believe it is not hard to find a split between data owned by the services, and that owned by the simulator. For the largest scale games, you would need both.
If the game is multiplayer, there will be significant amounts of data that needs to be exchanged but doesn't need to be persisted. Only really light weight games could afford for all data to go through the DB.
That wound up causing a fair number of problems for a variety of reasons; for example, we ended up having multiple databases with foreign keys into each other, without any good way of enforcing the constraints one normally associates with foreign keys. Some operations like character renaming turned into fragile distributed transactions.
For an extremely large-scale game you may have no choice but to take that kind of approach, but it is an opportunity cost that is probably not worth it if you have a few hundred thousand players.
I'd also like to emphasize the difference between "standard web technology" - using Java or PHP or ASP on top of a separate web server that largely uses a relational database for state and internal communication - with "web as medium" - making your simulation engine speak HTTP and using that as an additional window into game state. Taking the second approach nets you a lot of the gains from having game services available over HTTP, without having to completely change your simulation model handle game services implemented in standard web technologies.
So once you've abstracted the database into an API layer, why not put that layer closer to the game servers? And yes -- game services should be available over HTTP. Use the well-understood protocol, and save yourself effort.
had dentist visit on weds
I got a bit confused with my last comment, maybe. I wanted to say that, with people's own personal involvement, i felt very involved and comitted. Any maybe the future involvement we've got planned, the big 'bang', maybe it'll surpised and upset me. And we'll need some 1:1 shit!
I dunno. Toby, Zone, care to clarify anything?