It really depends on the kind of game. But, here's the "archetypical" architecture for an MMO game with player interaction and server-side rules enforcement:

A "typical" MMO "RPG" shards the world into "zones" where each "zone" is some physical area, with some kind of transition between them for a traveling player. The size and gameplay of each area is designed such that the maximum number of players in that area does not exceed the throughput available for a single server (typically SMP, in-core, shared state multiprocessing.) More complex game rules and more complex simulation/physics will reduce the number of players that can be in a zone, and/or increase the size of machine provisioned for that zone (and there is an upper limit to that size.)

"Instanced dungeons" are a gameplay design feature that helps with this, because each instance is sized to perhaps 10-50 players, which means it can fit on a smaller (virtual) server host, and load can be more homogenized. Some games also auto-instance the same world zone for the same world instance more than once -- City of Heroes did this for high load areas, for example. You'd have "Main Plaza #1," "Main Plaza #2," ...

Worlds, in turn, are horizontally sharded into what players see as "servers." So, if I play on the "Brlaghadepr" server in some MMO, that's really a set of character-database-plus-zone-instance-servers. There's a separate subscriber-database which actually contains all subscribers; this is typically sharded horizontally by customer ID or somesuch, but that database is only required for initial login, and for account status (banning, subscription, etc.)

Game state is largely kept in memory in the game servers, not in databases. Game servers checkpoint important state back to character databases on a periodic basis, as well as for things that have to be transactional (like player/player trade of valuable items.) Optimizing the CPU and RAM usage of the game servers is important to manage costs, and allow large crowds of players in the same virtual game-space.

Clients are either made to re-connect to different world instance zone instance servers as they move around the world, or there's a load balanced "gateway" role at the edge of the network, where the client talks to the gateway, and the gateway just knows how to forward client traffic to the appropriate server instances.


If you're building an MMOFPS, this architecture changes slightly. If you're building a game with player-hosted game instances, the architecture changes more. If you're building an asynchronously multiplayer game, like Farmville, the architecture changes drastically.
Because of the actual, palpable, benefits to gameplay from CPU and RAM usage optimization, each architecture tends to specialize for the particular game being implemented. Thus, there aren't really any two games that would be as well served by some generic architecture "platform" or "fabric" or "substrate" (other than "utility computing" like ECC/Linode/Rackspace/etc.) This is a requirement that is quite different from enterprise data, and enterprise people who don't understand this invariable end up failing.