Какую DB для мессенджера выбрать?
Популярные NoSQL решения не используют джойны поскольку это в любом случае ведет к сетевым походам на различные шарды. Даже если это скрыто от пользователя. Соответственно в распределенной системе вы не получите джойнов как в Postgre. Более того, если пытаться шардировать Postgre, у вас и там возникнет проблема джойнов между шардами и от подобных джойнов придется отказаться.
Проблема в том, что вы подходите к хранению  данных в NoSQL также как в RDBS. Это неверно и для распределенных систем вполне себе допустимо хранение избыточных данных. Вы вполне например можете записывать новое сообщение на множество шардов, на шард где хранятся сообщения группы и на шарды с юзерами. Делать это можно по событию, которое генерируется при создании сообщения, далее оно попадает в rabbitmq, а оттуда подписчикам, которые запишут сообщение на нужные шарды.
Таким образом, вы всегда сможете прочитать вместе с пользователем его новые сообщения с одного шарда. Делают по разному, основная мысль в том, чтобы максимально упростить сбор данных, для того или иного экрана приложения.
Например в социальных сетях так советуют собирать ленту новостей. Система принимает пост от пользователя, а затем сервис в фоновом режиме раскладывает этот пост по всем пользователям (шардам), которые этот пост могут увидеть. Соответственно отображение ленты новостей становится тривиальной задачей. Также нужно быть готовым к тому, что в распределенных системах принята согласованность по событию  вместо согласованности по транзакции. Проще говоря, не все пользователи увидят новый пост в своей ленте мгновенно, а спустя некоторое время и для больших проектов вроде facebook или amazon это ок. Из-за этого иногда на facebook можно обновлять ленту с переодичностью в секунду и в какой-то момент получить новый пост у которого дата добавления была 1 минуту назад.
По базам данных можно выбрать любую популярную с поддержкой шардинга из коробки, которая больше нравится или с которой лучше знакомы. Знакомы с кассандрой, отлично используйте её, знаете монго, берите её. Не знаете ничего, почитайте плюсы и минусы обоих систем и решите для себя, что больше вам подходит.
Master-slave полезно на случай отказа одного сервера, но по нагрузке и оно имеет свои пределы; и что потом будете делать? Более-менее сложная архитектура подразумевает встраивание сервера БД в архитектуру приложения так, чтобы оно горизонтально масштабировалось - например, с помощью шардинга. Поэтому рекомендую выбрать систему, с которой умеете работать и которая умеет реплицироваться. Но реализовывать её так, чтобы можно было масштабироваться путём добавления серверов именно к Вашему сервису, а не к серверу БД.