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

vsb>1. Использовать полновесный сервер очередей. Сто лет назад я работал с websphere mq. Наверное сейчас есть получше что-нибудь. Суть в том, что сервисы вместо того, чтобы дёргать друг друга, кладут нужные данные в очередь и забывают про это. Будем считать, что очередь работает всегда и данные в ней никогда не теряются. А принимающий сервис из очереди достаёт данные, обрабатывает, если не получилось обработать, то откатывает транзакцию и данные остаются в очереди, достаём следующие данные и тд.

На практике данные, естественно, теряются. Стандартный дизайн для надежной предачи данных из палок и желудей — положить данные в РСУБД, пульнуть нотификацию через какой-нибудь 0mq, с другой стороны принять нотификацию и забрать данные. А для того чтобы пережить временную недоступность сервисов, использовать heartbeat.

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

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

vsb>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.

Оно примерно так и есть. Значительная часть сложности системы ("сложности", в Холмогоровском смысле) находится не в коде, а в оркестрации сервисов. Из готовых решений для "оркестрации мышкой" могу предложить только AWS. Но с ней лучше не связываться без сертифицированного архитектора, знающего ограничения и возможности амазонвских сервисов.