[bermanoid]

I've got to agree - 1M daily users and 50k db hits per second indicates something is being done in a ridiculously inefficient manner somewhere, and I'm really surprised that the solution was to fiddle around on the server-side.

Suppose your players are active for an average of, say, 20 minutes - that's a damn generous upper bound for a Facebook game. That would mean that 1M / (24*3) = 13,888 users are active (on average) at any time. Which means that they must each be generating db events at a rate of about 3.6 events / sec / user, which is ludicrous (at the very least, these should probably be somehow combined so that each client only hits the db once in a while, preferably in response to a user action).

And in reality, the average play session is probably quite a bit shorter than 20 minutes, which means the event rate is even higher per active user. What the hell are they doing that is causing so much database traffic?

Is the game actually doing something a lot more sophisticated than I would assume it is based on the looks of it (to be fair, I've never played it), or is the client-side design just really that messed up? I mean, it's cool that they can handle that much traffic, and all, and the server guys should be proud, but IMO they should really be able to do better on the client-side to prevent this level of scaling from being necessary...

[joelhaasnoot]

Have you played these games? Everything you do on your farm/plot/area is a click on a tile. You're essentially trying to click on as many tiles in as little time as possible for your own sanity: there's no "select all".

[jules]

You can preload/cache all or nearly all data on the client side, and batch updates.

[jrirei]

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.