Илья

Ну и инициализируйте его правильно. В чем проблема?

public static Dictionary<string, float> Weapons = new Dictionary<string, float>(){
            {"a", 1f},
            {"b", 2f}
        };

Межсервисное взаимодействие ничем не отличается от клиент-серверного. Та же аутентификация и авторизация (тот же пресловутый openid credentials grant flow), тот же SSL. В некоторых редких случаях можно ограничиться white-list ip, но тут хватает ограничений и никаких ролей

Есть команда INFO memory — покажет сколько памяти занимает весь сервер со всеми данными.

Ещё может помочь MEMORY USAGE key чтобы посмотреть, сколько памяти занимает конкретный ключ.

как договоритесь, так и будет.
четкого и однозначного деления нет.

как сервер за столь короткое время умеет прошерстить базу данных, найти сообщения конкретного пользователя и отдать их

Я бы делал немного иначе, например пользователь отправляет сообщение, которое принимает сервер.
В случае, если получатель сообщения также подключен - сервер параллельно доставляет получателю сообщение, за счёт этого имеем быструю доставку сообщений, и параллельно сохраняет сообщение в базу.

Что касается быстрой загрузки истории сообщений - то тут нужно сохранять сообщения таким образом, чтобы сообщения одного пользователя всегда были на одном и том же сервере (если используется шардинг). Тогда обычный SELECT из базы по user_id будет вполне себе быстро работать даже на огромной базе. Также таблицы можно еще партицировать, чтобы еще быстрее загружать последние сообщения в истории.

Что касается безопасности, если не использовать e2e шифрование, как вариант, можно использовать обычные RSA ключи. Например на сервере генерируем два ключа, открытый отправляем кленту, он шифрует им сообщение и передает сообщение на сервер. Вы на сервере его расшифровываете при помощи закрытого ключа. Для отправки сообщения клиенту, можно сделать тоже самое. Клиент также генерирует два RSA ключа и открытый ключ отправляет серверу. Когда серверу нужно доставить сообщение клиенту, он шифрует сообщение открытым ключём, который ему высылал клиент и отправляет ему.

Мне тоже интересно узнать другие варианты решения этой задачи, буду следить за этой темой :)

Хорошее дополнение по хранению сообщения и организации поиска от Ильи
Распределение нагрузки решается шардингом — получается много небольших БД вместо одной огромной. Скорее всего каждое сообщение разбивается по словам/частям слов и сохраняется в поисковый индекс типа слово—message_id и такой индекс строится для каждого пользователя и тоже шардируется. При поиске сначала получаем идентификаторы подходящих сообщений из поискового индекса, потом выгружаем сообщения из БД с сообщениями.

Дополнение от Stalker_RED
только не "сообщения одного пользователя всегда были на одном и том же сервере" а сообщения из одного чата/канала/группы (включая чаты, в котором всего два участника). То-же самое касается построения индекса.

Да, бывает. И за вопросы, и за ответы, и за посты на форумах, и за комментарии под техническими статьями. Но самое главное - за старый код. И это хорошо. Часто это обозначает, что я сильно вырос с того времени, как стыдное написал.

А чем не устраивают официальные курсы от Microsoft + очень хорошая документация?

Официальная документация React

Ооо.... Вы это сейчас вообще серьёзно?

Если вы запускаете DBaaS платформу и не знаете что делать собственно с базами - то у вас не

Запускаю свою облачную платформу, код и архитектура создана с нуля.

У вас нет вообще абсолютно ещё ничего и уж архитектуры - в особенности. Кроме "идеи", над которой бьётся давно и много кто, при том имея ресурсы на собственные команды DBA.

Например: юзер пишет какой-то запрос и ему не нужно указывать на какой сервер что отправлять или откуда читать, для него это один сервер.

Значит этому юзеру достаточно ходить только на мастер.
Для сферического в вакууме приложения нет средств автоматически распределять запросы по репликам. И такое сделать вовсе невозможно без накладывания ограничений на использование. Например,
select somefunc();
Что делает эта функция? Она только читает данные и потому можно отправить на реплику или она пишет и потому должна быть на мастере? Хотите правильный ответ от контрибьютора postgresql? Это достоверно не знает даже сама база до тех пор пока не выполнит функцию.

Другой пример:

begin isolation level repeatable read;
select ...
update ...
commit;

Как максимум на запросе select вы должны уже знать можете ли вы эту транзакцию отправить на читающую реплику. Откуда бы вам это узнать заранее?
И прочие принципиально-нерешаемые вопросы.

DBaaS это не про большие базы. Как бы не хотелось маркетингу убедить в обратном. Это про небольшие или стартующие проекты, где проще переплатить сервису за относительно вменяемую настройку и сопровождение типовой конфигурации.

Во-первых - У приложений будущего может не быть бэкенда - как бы немного не тот посыл.
Во-вторых - Саму статью не читали? Да, приложения смогут (на самом деле уже давно могут) обходиться без написания апи, используя готовые сервисы (которые тоже кто-то должен написать), ну и как всегда - получится тупое формошлепство, которое в итоге все равно подходит далеко не всем, то есть при создании более-менее серьезного функционала все равно придется пилить свой бэкенд, либо платить готовым сервисам неадекватные деньги за допиливание функционала. Ну и деньги, скорее всего будет дешевле 1 раз написать свое, нежели платить аренду сервиса за апи...