Это полностью проекто зависимая штука. К микросервисам стоит выростать из монолита. Микросервис по хорошему должен покрывать полностью конкретный домен, но им же и огранививаться. Вот тут как раз и кроется сложность. Если вы никогда не реализовывали проекты конкретной области, вероятнее всего вы разделите микросервисы не правильно, что усложнит и удорожает поддержку. В худшем сценарии ваши микросервисы будут чем-то вроде REST вокруг таблички в БД.
Представьте, что часть микросервисов вашего проекта делает команда иностранных инженеров, плохо говорящих на английском и что бы решить хоть какую-то проблему о взаимодействии с их сервисами, вам потребуется неделя, а то и несколько. С такими мыслями стоит подходить к этому вопросу. В идеале изменения у них не должны влиять на вас и наоборот.
Пример плохого разделения для задачи отправки писем по событиям (регистрация, новости, маркетинг...):
Сервис_А подготавливает данные и дергает Сервис_Б, что бы тот запихнул их в шаблон и отправил почту.
Подход плохой потому, что каждое новое сообщение требует изменений И Сервис_А И Сервис_Б, причем синхронизированных.
Та же задача, но с более лучшим решением:
Сервис_А отправляет события в стиле "юзер зарегался", "юзер сделал покупку",... Сервис_Б самостоятельно решает, что и когда отправлять ползователю.
В этом случае Сервис_А и Сервис_Б зависят друг от друга по минимуму.
