Если использовать node.js для серверной логики, то тут есть плюсы и минусы. Плюсы начнём с того что это лёгкость в модифицируемости и скорость разработки - минусы, конечно C++ с правильными руками будет намного мощнее.
Но критические зоны, например коллизия и математика без проблем может быть вынесена в C++ Addon'ы (модули) для node.js, что также можно делать позже (но не слишком).
Относительно сетевого трафика, тут по любому нужно писать свой сериализатор а не использовать тот же socket.io, т.к. унаследуешь кучу проблем от него, которые например Unity вообще не упали. Плюс если писать свой протокол, то можно нормально стримы заюзать от TCP, а не пакетно обрабатывать всё.
Парсер снова, может быть вынесен на C++, и там уже генерить V8 объекты (JSON), которому node.js будет рад.
Есть вот такой протокол, очень многообещающий:
http://kentonv.github.io/capnproto/
Также очень зависит от архитектуры твоего игрового сервера.
"ММО, МООшке рознь". Ты упомянул комнаты/зоны, речь идёт о разбиении мира на зоны (как в давние времена в WoW с предзагрузкой при переходах), или как в EVE, или речь идёт о матчах, как в LoL / Dota 2 / BF3 и т.п. играх?
БД, как jimon сказал нужно качественно кластерить и иметь возможность восстановления реплик.
БД использовать для редко нужных данных и периодическом сохранении данных, необходимых для восстановления игрового состояния.
Большинство данных должно держаться в раме и там же оперироваться игровыми серверами, периодически паралельно сохраняя то что нужно в бд.
Если сервера должны обмениваться данными между собой (сервера в плане процессов), то заводи redis, т.к. он очень эффективен для реалтайм быстрых транспортов. Redis - это реалтайм хранилище, подобно простой бд с разными плюшками.
Если тебе нужно общаться между серверами напрямую - например lobby сервер может поискать игровые сервера, и если lobby имеет приоритет на игровыми, попросить игровой сервер на создание игровой комнаты. В подобной ситуации тебе нужно напрямую общаться между серверами.
Тут я бы посоветовал ZeroMQ, он и прост и сложен. Просто для старта, и сложность заключается не в самой либе, а возможностях для сложных архитектурных решений коммуникации между процессами.
Даже логин сервер - должен скейлиться.
Авторизация - это побочный процесс, как addon в процессе, его задача получить данные логина, авторизировать/отклонить, и закинуть данные сессии в redis чтобы другие сервера/процессы могли получить эти данные, также сообщить запрашивающему процессу о статусе авторизации.
Я бы также совмещал RESTful с Real-Time. Большинство должно быть как раз RESTful до игры, а сама игра Real-Time.
Отличная практика для развития в этой сфере - это анализ существующих игр и их архитектуры.
Вот список рекомендуемых примеров: EVE; FireFall; Dota 2 / LoL; BF3.
Каждый из этих примеров утилизирует REST и RT везде. Что-то на REST'е, что-то на RT (realtime).