Привет!

Раз уж я тут все равно говорю про асинхронный обмен данными, то напишу про ещё один способ - transactional outbox pattern. Хотя, скорее, это не прям отдельно существующий способ, а дополнение к имеющимся брокерам, для увеличения степени надеждности их использования.

Суть данного паттерна заключается в том, что если нам необходимо наладить асинхронную интеграцию между двумя системами и при этом мы боимся потерять транзакцию в момент ее записи в брокер сообщений, то нам нужно создать еще одно дублирующее асинхронное взаимодействие, только уже с брокером (помним, что несмотря на то, что использование очереди является асинхронным обменом данных - в саму очередь мы кладем данные синхронно, и вот в этот момент у нас может пойти не так что угодно и сообщение до нее не дойдет).

В большинстве случаев, это уже совсем избыточно, но если нам прям критично важно не потерять ни крупицы информации, например, когда мы работаем с созданием каких-нибудь заказов\платежек и всех этих чертовски важных финансовых операций, то нет понимания "избыточно".

Чтобы избежать проблем с потерей информации - нам необходимо создать outbox таблицу, в которую будет дублироваться бизнес-объект при его создании. Т.е. в тот момент, когда по процессу создается объект, он кладется не только в свою таблицу, но еще и в таблицу outbox одной транзакцией, что значит - либо объект будет записан в обе таблицы одновременно, либо не будет записан вообще (это видно на схеме).

Хорошо, мы создали дублирующие записи в непонятной табличке outbox - и что дальше? А дальше, раз в n секунд у нас отрабатывает специальный сервис (так называемый процессор), который обрабатывает все сообщения из таблички outbox и кладет их в очередь сообщений. Если он получает от очереди успешный ответ, что сообщение доставлено и получено брокером - запись удаляется из таблицы outbox. Само собой, если по каким-то причинам у него не получилось положить сообщение в очередь (она не подтвердила получение сообщения) - эти сообщения не удаляются и через n секунд будет повторная попытка их обработать.

Плюсы:
- Решает проблему связи между сервисами. Теперь не нужно беспокоиться, что брокер или сервис доставки будут недоступны. Все сообщения сохраняются в базу и будут обработаны, когда недоступные сервисы оживут.
- Сообщения отправляются, только когда транзакция базы данных подтверждается. То есть у нас не получится так, что если нам не удалось сохранить объект в базу, и при этом получилось сохранить сообщение в Outbox, то выполнится не нужная команда. Здесь гарантируется атомарность.

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

Ссылка на официальную статью - https://microservices.io/patterns/data/transactional-outbox.html (кстати, рекомендую этот ресурс всем, кто так или иначе участвует в проектировании микрсоервисной архитектуры).