Кто подскажет ответ по ряду вопросов?

1. непонятна схема взаимодействия "микросервисов", почему возник такой вопрос, почему нельзя на сокет-сервере держать пользователей?

2. циклы можно подкрутить, если возлагать обмен на низкоуровневые потоки и события, для миллиона клиентов поднимаются несколько серверов с группировкой и балансировкой.

Сергей Сергей, тогда вопрос следующий.
Каким образом можно ввести горизонтальное масштабирование Node.JS с Socket.IO, чтобы данные о сокетах были доступны для всех серверов?

_{теоретическая прикидка}
На головном сервере есть некоторые сведения о всех пользователях и метках с указанием, какому сокет-серверу они принадлежат. Головной сервер сообщает сокет-серверам, какой из них обладает интересующими их пользователями и метками. Так сокет-серверы о пользователях и метках будут общаться между собой. Сообщение от одного пользователя до другого пойдет или через общий сокет-сервер, или через два сокет-сервера, которые уже будут знать об этих двух пользователях.
Стоит подумать над тем, есть ли в логике приложения прямые запросы от пользователей друг к другу, которые невозможно предсказать, такие запросы будут проходить через головной сервер и порождать поиск.
Конечно, всё обрушится, когда пользователи и метки все вместе окажутся внутри какой-то минимальной зоны.
Вычисления критериев на "попадание" придется как-то разделить. Например, распределить пользователей и метки по зонам, по степени удалённости зон исключать вычисления.

Сергей Сергей, а общение головного сервера и сокет-серверов посредством API, верно?

Сергей Сергей, а потом при той же отправке сообщения можно будет использовать нечто вроде:

socket.on('send message', function(data){
  var get_options = {
    method: 'GET',
    uri: 'https://ss1.example.com/getServer:'+data.userID+''
  };

  request(get_options)
  .then(function(response){
    // Здесь парсим полученный от головного сервера JSON и вытаскиваем из него сервер другого клиента, а далее отправляем на другой сервер API запрос, показывая, что нам нужно отобразить сообщение для пользователя userID
  })
  .catch(function(err){
    // Обрабатываем ошибку, если не удалось достучаться до головного
  });

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

Сергей Сергей, а при присоединении нового пользователя, соответственно, сохраняем его в "кэше" нашего сервера, а так же отправляем запрос на регистрацию пары ключ=>значение (userID=>serverID) на головной сервер. Все правильно?

API в виде протокола обмена — между серверами постоянное соединение логичнее держать.

Запросы на поиск пользователей по идентификатору надо свести к минимуму. Тем более, что о видимости между пользователями обычно должно быть уже известно сокет-серверам после вычислений "попадания". И гадать, куда обращаться к пользователю не придётся — хранимые на сокет-серверах списки о пользователях ведь с такой меткой и предусматриваются.

Да, подключающиеся пользователи запоминаются на сокет-сервере и на головном. И (повторю) при надобности осведомляются остальные "заинтересованные" в ходе вычислений сокет-серверы. Привязка сокет-сервера и пользователя по идентификаторам есть "корень" такого взаимодействия.

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

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