Есть два процесса, работающих с одними данными. Один процесс изменяет данные. К примеру создаёт новую запись. Второй процесс должен понять, что запись создалась и обработать её.
У меня возникают проблемы с тем, как правильно спроектировать транзакцию в БД и работу с очередью.
Первый подход:
- Вставляем строку
- Коммитим транзакцию.
- Отправляем в очередь событие с ID строки.
- Получатель получает событие.
- Получатель запрашивает данные по ID и работает с ними.
Тут возникает проблема между шагами 2 и 3. Если процесс умер, то запись окажется в БД, а получатель про это не узнает.
Второй подход:
- Вставляем строку
- Отправляем в очередь событие с ID строки.
- Коммитим транзакцию.
- Получатель получает событие.
- Получатель запрашивает данные по ID и работает с ними.
Тут тоже возникает проблема между шагами 2 и 3. Во-первых транзакция может не закоммититься, а событие уже ушло. Во-вторых получатель может получить событие раньше, чем транзакция закоммитится и не увидит данные.
Можно накрутить какую-то сложную архитектуру с дополнительным полем-статусом, двумя коммитами, «восстановлением» если второй коммит не сработал, получателем, который нормально отрабатывает двойные сообщения. Расписывать не буду, но это всё прям очень сложно выходит.
Самый простой вариант это использовать что-то вроде postgres listen/notify, который умеет отсылать события транзакционно. Но интересует именно работа с внешней очередью, без всяких там двухфазных транзакций и подобного энтерпрайза. Кажется, будто упускаю что-то очевидное.
Если нужна конкретика - пускай будет postgres и kafka
