Здравствуйте, vsb, Вы писали:

По-моему направление верное. Общение между сервисами надо организовывать сообщениями, а не request-response. Всё очень упрощается.
websphere mq — и аналоги это по-моему жуткий монстр, прошлый век.

vsb>2. Использовать легковесный сервер очередей, что-то вроде kafka. С ней я толком не работал, но представляю это так: в очередь кладём не данные, а только id. На отдающем сервере делаем endpoint, который по этому id отдаёт данные.
а если отдающий сервис в это время перестал быть доступным? Нужно отдельное хранилище организовать.

vsb> Принимающий сервер вытаскивает id, а данные вытаскивает уже из отдающего сервиса по этому id. Этот вариант нравится чуть больше, но в целом тоже полагаемся на то, что сервер очередей работает 100% надёжно, не уверен, что kafka этому соответствует.
Кафка надёжен, но надо внимательно разобраться как правильно организовывать надёжный кластер, но это не рокет-сайненс, разобраться можно. Его можно использовать даже в виде своебразной базы данных, как постоянное хранилище.
Единственный тонкий момент, что он не предназначен для посылки массивных сообщений. По дефолту максимальный размер сообщений около 1мб. Оптимально лучше, если сообщение порядка килобайт. Если у тебя всё укладывается в такие ограничения, то всё круто.
Если тебе нужно передавать большие порции данных, то тут два варианта:
— упомянутый тобой id+отдельное хранилище (можно это назвать сообщение с аттачментами), это имеет смысл если сообщение содержит некий неделимый блоб (или несколько), ну видеоролик какой-нибудь многомегабайтный.
— либо разбивать массивные сообщения на более мелкие, это хорошо в случае если в данных есть какая-то структура. Напимер, вместо того, чтобы посылать 100тыс строк csv, ты посылаешь 100тыс сообщений на каждую строку.