Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.

Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать. Поэтому в первом сервисе заводим статус service_2_sent, заводим cron job, который делает select по этому статусу и допуливает данные во второй сервис. То же делаем во 2 сервисе. В итоге у нас целая куча cron job-ов, всё асинхронно пуляется туда-сюда, в бд куча статусов, в общем всё сложно. Ещё нет наглядности, когда что-то не работает, приходится лазить по сервисам, базам, логам и тд.

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

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

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

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

3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд. Тогда мне это не понравилось, показалось, что сову натянули на глобус. Но может быть тот движок был плох, сейчас мне кажется, что такой подход был бы хорош. В моём понимании надо нарисовать бизнес-процесс, движок должен отслеживать статусы, повешать вызовы, например rest-методов на переходы, движок должен отслеживать fails, а также рисовать красивый интерфейс, в котором можно найти конкретную сущность и связанный с ней граф и посмотреть, на каком шаге оно находится, какие ошибки произошли. Прописывать правила retry, удлинение времени вызова и всё такое.

Пункт 3 не нравится тем, что на такой движок всё будет завязано и его ограничения могут вылиться в боль. Менеджмент предлагает использовать airflow в виде такого движка.