[moka]

1. Дело в том что обработка учётных записей, нахождение игровой группы (например как в League of Legends, ждёшь пока не найдутся по рейтингу подходящие игроки), и обработка самой учётной записи - не относиться к игре как таковой, и это не сложная задача. Следственно такой сервер может быть один. Или несколько разделённых по регионам. Вполне качественно разработанный Lobby сервер может держать десятки и порой сотни тысяч клиентов.
Игровой же сервер имеет высокую нагрузку, т.к. занимается игровыми вычислениями, следственно на том же железе, можно будет запустить ограниченное количество матчей. Поэтому используют динамично масштабируемую инфраструктуру, где при необходимости выделяется больше железа под игровые сервера и запускаются матчи на них.
Например используя AWS (Amazon Web Services) и EC2 инстанции. Или Google App Engine (тоже облачные серверы).
Следственно для возможности расширения, тебе нужна возможность выдержать огромную нагрузку, и делать это максимально прозрачно от пользователя.
Большие игры, такие как League of Legends - это огромные затраты на сервера, следственно там должна быть какая-то монетизация, иначе оплачивать такую инфраструктуру для возможности поддерживать такое количество игроков - слишком дорогое удовольствие.
При глубоком анализе и исходя из опыта и тонкостей приложения, можно посчитать сколько в чистом будет стоить обслуживание например 1,000 пользователей в сутки. Или скорее 1,000 игровых матчей. Зависит уже от специфики приложения.

2. Существуют, и серьёзные.
Во первых пересмотри взгляды на хранилище данных. Что нужно хранить, нужны ли там непосредственно игровые данные (позиции игроков, золото и т.п.) или не нужно. Если это опять пример LoL то не нужно хранить - что очень спасает ситуацию. Если это WoW то тут всё намного сложнее.
При больших и сложных системах не используется прямой доступ к БД никогда, используются БД прокси сервера, которые используя определённый протоко будут принимать пакеты и запросы на запись/чтение, эти запросы все валидируются, и затем уже эти прокси сервера общаясь между собой согласуют доступ к данным напрямую из БД.
При этом для игр я бы не использовал SQL тип баз данных, т.к. таблицы громоздки, обычно для хранения одной записи даже с пустыми ячейками нужно слишком много памяти. Слишком много проблем с кластеризацией таблиц и т.п.
Я бы посмотрел в направление NoSQL баз дынных, таких как например MongoDB - где данные хранятся в документах JSON формате, и нету определённых правил хранения и структур данных - это зависит от разработчика. При корректном подходе при росте количества данных, скорость записи / чтения не будет снижаться так как в SQL типах баз данных. Что в крупных проектах очень важно, и следственно оправдано. Тем более JSON намного удобней формат для хранения сложных структур данных, нежели строки в таблицах.

3. Влияет, читай чуть выше, а также тебе нужно будет учиться кластеризовать таблицы / документы. Например если логин - выступает в роли идентификатора, то можно разбить таблицу на много таблиц где каждая будет отличаться от первого символа логина. Например для пользователей с никами: alex, andy, android будет одна таблица. Подобных идей может быть много, но учитывая специфику потребностей - это не всегда удобно, и будут требоваться дубликаты данных, в других таблицах чтобы например искать по ID - что другая тема.

4. Никакого внешнего доступа к прокси серверам БД, только локальный. Никакого физического доступа. Хранение паролей в хешированном виде. Также и к email'ам - но тут не всё просто. Т.к. иногда нужен доступ к эмайлу. Чтобы реализовать хешинг эмайла, тогда нужно реализовать логин по эмайлу, таким образом если пользователь залогинился по эмайлу (так же как и пароль - хешируем эмайл и пароль, ищем в бд данные с этими хешами), далее после успешной авторизации храним эмайл в сессии. Это хранит Lobby сервер, и может предоставлять это данное только внутри своей сети инфраструктуры. Когда пользователь дисконнектиться по любой причине, сессия истекает, и данные о эмайле теряются снова.
Таким образом даже если кому-то удастся получить доступ к данным в бд, ему не удастся получить список эмайлов или паролей - т.к. они хранятся кешированные, а кеш это односторонний процесс, следственно никакого реверс кеширования и возможности получения эмайлов и паролей.

С платежными системами всё сложнее, и тут нужно обращаться в компании сертификации и получения регуляций и разного рода инструментов для организации защищённого хранилища платежных данных пользователей.