Если "чат/мессенджер/что-то подобное", будет лежать очень много данных. То есть профили можно сохранить хоть в Postgres + Redis (шардированный по регионам), и иметь вполне себе хорошую производительность. Проблема будет именно с сообщениями.
Если решать проблему по логике "почему бы не стремиться к 8 млрд пользователей", для профилей можно взять Aerospike или Tarantool. Оба решения имеют возможность шардирования по вторичным ключам, так что их можно разнести по разным регионам. Причём надо именно шардироваться, а не только реплицироваться. Таким образом, можно избежать "узких горлышек". В этом случае оба решения будут выдавать более миллиона запросов в секунду на один кластер с маленькой задержкой (скорее всего двухзначной в медиане) и не иметь единой точки отказа.
С сообщениями сложнее, так как их будут петабайты. Тут советую не "изобретать велосипед" и взять ScyllaDB, как это сделал Discord. ScyllaDB работает с огромными массивами данных довольно быстро и прекрасно масштабируется. Ради двухзначных чисел задержки в медиане достаточно шардироваться по регионам.
Выводы очень простые. Если "стремиться к 8 млрд пользователей" надо
1 - использовать нереляционные СУБД
2 - шардировать БД по регионам (тогда можно отказаться от очередей)
3 - использовать кэширование "горячих" данных
4 - использовать Write-Optimized СУБД для больших массивов данных.
Если у Вас "8 млрд пользователей" Вы можете позволить себе по датацентру в каждом регионе, поэтому основной задачей является правильное шардирование. И ещё один совет. Если гнаться за производительностью, надо использовать не очереди сообщений, а многопоточные асинхронные серверы, которые "кучкуют" сообщения пачками, чтобы как можно реже обращаться по сети.
