я неспешно размышляю за транспорт, а конкретно: условно есть две парадигмы - push когда сервисы сами посылают нужные данные в другие сервисы (http1/2, grpc и тп), и pull когда сервисы подписываются на события и обрабатывают логику в зависимости от изменений (amqp и прочие общие очереди)
в своих системах я нашел удобным миксовать оба подхода: push для прямых вопросов "сервис X, я сервис Y, дай мне эти данные ибо ко мне обратился клиент через REST и мне они нужны чтобы выполнить бизнес-логику и ответить клиенту", pull для бэграунда чтобы четко разделять доменную логику "всем привет, я сервис Z, я буду получать события от сервисов A и B потому что когда у них обновляются данные мне нужно у себя поставить соответсвующие флаги"
однако, я заметил что во всех решениях продвигается только одна модель - push (тот же istio в кубере, 99% фрейворков и тп)
у этой однобокой архитектуры есть свои плюсы (если все общение через http то проще написать сервис на другом языке не вкладываясь в доплибы), и свои минусы (логика оповещения всех зависимых сервисов висит на сервисе который изменяет состояние что усложняет бизнес-логику)
в связи с чем вопросы:
1) почему так - это тренд? у этого решения больше плюсов и поэтому выбирают? какие плюсы и минусы видите вы?
2) вы к чему пришли - используете один из подходов или тоже миксуете?