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

Я для примера написал. У меня кейс - ретрай задачи по экспоненте 7-8 раз в случае фейла.

Код взаимодействует со сторонними сервисами и фейлы- обычное дело

Тогда наверное проще как в первом варианте - передавать реальный ETA как параметр таски, и делать не retry, а просто повторно ставить эту таску с уменьшением значения этого параметра. Хотя придётся ещё передавать число ретраев.

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

Я к этой простой мысли шёл довольно долго, кстати...

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

Ну да, ровно то же самое. Но пока у тебя полтора юзера, можно не заморачиваться.

У нас ведь кроме прочего Монга без транзакций - это ещё добавляет градус рандомности во всё происходящее 😊

У нас тоже монга и отсутствие транзакций. И это прекрасно! Вот уж чем мы до сих пор довольны, так это выбором БД.

Значит вам повезло, что все ваши важные изменения можно делать одним запросом к одному документу. У нас вот так не вышло, поэтому следующая большая фича будет использовать транзакции.

Нам не повезло. Просто мы научились работать с атомарностью достаточно хорошо.

Ну мы тоже как бы не лыком шиты. Но кейс когда надо атомарно (и ещё с изоляцией) изменить две коллекции не получилось адекватно решить ни какими двух-фазными коммитами или запихиванием всё в один документ.

Когда я слышу про изоляцию, я, обычно, спрашиваю о том, зачем она нужна конкретно в этом кейсе. Я очень мало встречал ситуаций, когда она действительно важна.

Но бывает и такое. Для таких редких кейсов нужна другая БД.   🙂

Монга норм база, если использовать её по назначению и не пытаться заменить СУБД

У нас надо менять файл/папку пользователя и сохранять это изменение в историю. История используется для синхронизации изменений на клиентах. Нельзя допустить, что бы например файл/папка в базе был создан раньше чем запись в истории о создании. Это может привести к тому, что в истории может появиться запись о создании файла раньше чем в ней появится создание папки, внутри которой этот файл находится.
Поэтому и нужна изоляция, что бы никто не видел изменений до конца транзакции.

Не так. Не надо пытаться заменять ей СУБД, потому что она и есть СУБД.

Уж столько лет прошло. Я думал вы все на постгре переписали

СУБД и монга это вообще 2 разных мира. Не вижу смысла проводить аналогии