THANK YOU! I've simply forgot to mention those guys, added now, see added "Web-Based Game Deployment Architecture" section and (also added) strongly related "Taming DB Load" subsection. Don't hesitate to let me know if you feel that there is something wrong with them.
Regarding deployment diagram... if there is a matchmaking server, it's clear where to connect initially; indeed, matchmaking servers are mentioned in plural. If it is an intention, then how to choose between them?
Usually, if there is more than one matchmaking server, all of them are well-known and one of them is chosen at random (either via round-robin DNS, or via client-side balancing, more details on these will be discussed in Chapter VI(b)).
Awesome stuff as always, looking forward to the rest of this chapter!
One quick question: a lot of async multiplayer games (like social games, or turn-based combat games) also run over HTTP instead of raw TCP or UDP sockets, and so they tend to have a different server-side architecture that looks more like a web site. (Especially: stateless http servers that keep game state in network-attached memory caches.)
Are you planning to discuss these kinds of architectures as well, or are async / http games outside of the scope of the book?