да, разруливает, если не потеряет. а если потеряет, то синхронизировать с базой вам нужно.
а кто будет источником правда ? упавшая база или упавший кролик ? или кто упал позднее?

это все требует проработки. это не для детей

это не для детей и потому оч грустно что для пыхи ничего нет

а куда ты сохраняешь фейловые сообщения? DXL?

я смотрел мне не понравилось

и что с ними потом происходит?)

ты не одинок, ибо там какой-то совсем другой мир. Не оч знакомый всяким решётчатым парням и парням из мира жвм

но концепт тоже имеет право на жизнь

а хоть на чем-то есть удобный инструмент для саги ? я как-то всегда все руками делал в этом направлении

он за год 1.4к лайков набрал, они деньги вкидывали туда?)

не, просто надо уметь торговать лицом :)

php-service-bus, дед местный сделаль, работает отлично

а они все в убере работают? темпорал чуваки

Индепонентная обработка (а она нужна ибо очереди не гарантируют что придет только одно сообщение они гарантируют что хотябы одно) и ACK только после закрытия транзакции решают все эти проблемы

там есть косяки с ретраями, всё никак руки не дойдут закончить обновление.
ну короч ретраи у меня сделаны на отвали. совсем

условно говоря есть три уровня. Первый уровень - сообщения на обрботку. Там все обработчики тусят. Если у них чет пошло не так (reject) то сообщение кроликом отправляются на второй уровень. В том числе и если обработчик по какой-то причине не сделал ack и сообщение пришло второй раз с redelivery=true (мы не можем по другому убрать риски poison message).

На втором уровне тусит обработчик который для сообщений настраивает политику ретраев. Он берет энвелоп и для него прикидывает сколько раз уже выполнялось и сколько надо настроить делей. Дальше оно пишет в базу что мол "через 30 секунд попробуй заслать этот энвелоп еще раз". Так сообщение возвращается на первый уровень. Если количество ретраев больше чем мы разрешаем для сообщения - кидаем nack и сообщение автоматом уходит на третий уровень (fallback queue).

Если дошло до fallback то дальше как бы можно записать в базу (на память и для дебага) и если что сделать даже UI который позволяет эти сообщения закидывать обратно на первый уровень.

Если у тебя класстер кролика в pause minority + есть publish confirms то в целом вся схема весьма надежная и потерять сообщения становится весьма сложно.

А да важный нюанс - ретраи у меня работают так как мне нравится за счет того что роутинг вынесен на клиент. Мол там где мы отправляем сообщения инфраструктура чекает кто будет обрбатывать (в том числе айдишка саги вычисляется на этом этапе). Для каждого обработчика мы формируем комию сообщений что бы политики ретраев были независимы

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

нет, хранить лог обработанных не поможет.

короч я просто слизал подчистую как примерно nservicebus работает и в целом я доволен

на реализацию ушло где-то 2 недели (часов 40) + пара месяцев чтения статей и доков