⚡ Kotobotov ⚡

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

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

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

обычно микросервисы нарезают так чтоб они обслуживали отдельную "тематику", которую можно было бы отдельно маштабировать и отдельно дорабатывать, от всех остальных. Пример:
микросервис который обрабатывает работу каталога (и всё что связанно с ним), отдельно микросервис который будет работать с доставкой и отправкой заказов, микросервис который работает с партнёрской программой и начислением балов лояльности, и микросервис который занимается обработкой платежей. У каждого из этих микросервисов желательно иметь свою БД, тогда они могут независимо друг от друга работать и независимо маштабироваться, только отвечая потребностям свой нагрузки - очевидно нагрузка на каталог сильно выше чем на сервис обработки платежей (например каталог может обрабатывать 10 узлов, заказы обрабатывают 3 узла а платежи 1 узел)
При использовании монолита вы масштабируете сразу все сервисы на узлы, что не так эффективно.
-------
По поводу перфоманса - при такой нарезке как описал выше, у вас крайне редко будет ситуация когда для ответа на один запрос от пользователя, нужно будет опрашивать сразу несколько сервисов, НО даже в таких ситуациях не так важна задержка между вызовами, сколько возможность масштабировать обработку этих запросов.
-------
транзакционность обычно осуществляется через SAGA паттерн.
По поводу консистентности - если ты начинаешь масштабировать систему, значит состояние размазывается по множеству разных узлов/сервисов, вся суть что эти узлы/сервисы могут независимо друг от друга работать, значит консистентность будем мешать независимой работе (тоесть производительности), если сервисы зависимы то они не маштабируются (раз один узел ожидает что-то для работы от другого узла), поэтому там предъявляются "ослабленные требования" к консистентности состояния, как правило используют eventual consistency (согласованность в конечном счете), говорят что рано или поздно типа состояние в системе будет согласованно, если не будут поступать новые данные)
ну а пока данные поступают, то состояние может быть не согласованно между узлами.

>Логично ли все базы свести в одну и из разных сервисов
это логично только когда не корректно провели декомпозицию функционала и пытаются просто нарезать один сервис на разные части с единой базой,
для разных микросервисов это не должно быть логичным.
например у ресторана в сервисе "доставки блюд" и в сервисе "оформления блюда", есть и там и там "клиент", но данные этого клиента в обоих сервисах разные.
в доставке у "клиента" есть ФИО и адрес,
в оформлении блюд на выдачу в ресторане, у клиента ни адреса и ни фио (просто клиент №1 например), но есть например номер столика и тд
для обоих этих микросервисов источники данных разные.

>Bind user to node after login
что первый вариант что этот - не очень решения при распределенной архитектуре.
====
вам нужно переделать мышление, о том как вообще следует выстраивать работу в распределенных архитектурах.
но ничего страшного, можно начать с курсов на курсере или что-нибудь в таком стиле посмотреть
потом можно говорить о каких-то конкретных подводных камнях.

для улучшения поиска коллизий полно алгоритмов, обычно они ориентированны на то чтоб "ПОЛЕ" разделить на сектора, и искать коллизии только внутри точек с общими секторами.
в рамках микросервисной архитектуры каждый "микросервис" может обслуживать свой небольшой сектор.
ваша задача найти выгодную схему нарезания на сектора, предположу что нужно будет использовать алгоритм хэширования (разделения на сектора) с двумя переменными такие как (размер и расположение сектора и его средняя загрузка, чтоб в среднем была равная загрузка секторов на обработку данных), наилучшую формулу вам нужно будет найти опытным путем.
есть само собой и другие подходы.
не вижу какой-то необходимости что-то с пользователями кэшировать. Лучше обеспечте локальность данных, тоесть размещайте данные (БД) в том же самом месте где их и обрабатывайте, это главное правило для масштабируемой и производительной архитектуры построенной на микросервисах.