Well, there's this book -- which is a bit old now, and I've never really read it, but it's from a reputable publisher. I also found this one, which is newer, but I've never heard of before. Both claim to cover MMO (or at least online) game development issues; that said, client-side prediction is more or less the same regardless of the scale of your concurrent player base, and Google has plenty of information about it.
It's important to realize that from a practical perspective it's rather hard for an indie/hobby developer to put together a game that will be popular enough to even garner enough players to achieve a theoretical peak concurrency high enough to be considered "massive." But the techniques can still be educational to research.
There are two major classifications of things you can do:
- Be aggressive about sending only the minimal amount of data to the minimal set of clients that need it.
- Design a game that doesn't give players incentive to clump up too much, helping you keep the "set of clients that need" things small in general.
The second one is really a game design and social manipulation problem -- it's especially tricky because multiplayer games are naturally social, that's part of their appeal, so you don't want to discourage clusters of players too much. On the other hand, a game where everybody in the world is spawn-camping the one guy who drops the best loot in the game is going to be hard to scale.
For the first option you could consider doing tiered messaging -- there are some things about other players that are always important to know, such as positions. But other things, such as health, may not be as important for objects that the current player cannot see yet, so you gate what you send to that player based on the relative distance of all other entities in his vicinity -- this is essentially throttling the data you send, as you mentioned in the last bit of your question, as well as filtering it.
Very large scale multiplayer architectures will also buffer reports that don't need to have immediate action taken on them. Character save messages sent to the server can be done in deltas, with full updates only at critical points, and these updates can be buffered up on a throttling server so that they are send to the server that actually holds the character data in a steady, periodic fashion -- as your player base scales, you have to worry about optimizing disk IO as well as network traffic. You don't want to cause your character database to thrash.
The packet rate and size differs widely from game to game, just as it would for non-MMO games. It's really a very requirements-specific thing and there aren't generalized standards.
