For Monster World we did not consider this as the game is running fine (or good enough) as it is now. During the last weeks we were more focused on reducing RAM consumption of our databases as that is currently the main driver of cost and operation overhead.
Regarding your idea: Wouldn't then the Node.js server have to keep the whole user state in memory?
We did go for Ruby in order to increase developer productivity (having a very small team of just two developers), and good code quality/high test coverage. We were sure we needed to refactor a lot later on. So Ruby seems like a good choice.
But Ruby is NOT good at waiting no a database / network latency. But I guess with PHP we would have had exactly the same problems.
You are right: "no cache" means no cache in the app layer, so no eviction logic and inconsistencies between an app-layer-cache and a database.
And yes the best thing a cloud can offer is lots and lots of memory. That's where it's good. And I/O (disk & network) is where it's weak.
We do preload all data on client side as the client must never wait on server responses for better user experience. But we cannot batch on client side as we cannot foresee when the user will kill the client.
And actually we have more than 40K parallel user sessions as players come back more than once each day.
The presentation was recorded by InfoQ. I hope they will make it available during in the next 1-2 months. There's a lot I said but did not put on the slides.
You are correct in your assumption that each Tile had been a record in a MySQL table (now it is a value i a Redis hash).
Actually we considered using a "blob" approach. But in the client we cannot batch requests as we cannot foresee when the user will simply kill the Flash client to go to some other site. So when a user request (i.e. a game event) arrives in the server there is no way to know if another request will follow. So we have to persist that change right away.
This is using a stateless server. In a later game called Magic Land we are going for a stateful Erlang server. There we keep the whole user state in RAM while the user plays and persist state changes every minute or so. Here we can do without any database and just use S3 for persistence. Works just great. On the upcoming Erlang User Conference we will give an update on that project and slides will be available at Slideshare next week, too. In the meantime please have a look at this old slide set to explain the concept in detail: http://www.slideshare.net/wooga/erlang-the-big-switch-in-soc...