Здравствуйте, ·, Вы писали:

·>Я не предлагаю менять постановку задачи, а менять реализацию. Если нам нужен AoN режим (all-or-nothing) мы просто реализуем откат зарезервированных позиций при отмене зарезервированного (частично или нет, неважно) заказа.
·>Суть в том, что размер транзакции разумно ограничен, а не зависит от размера заказа.
К сожалению, у этого подхода есть семантические последствия.
Например, если два пользователя заказали товары А и Б, причём первый успел зарезервировать последний А, а второй успел зарезервировать последний Б, то в ACID один из них получит отказ, а другой заберёт всё.
А в вашем подходе оба заказа будут откачены, и мы получим двух недовольных кастомеров плюс непроданный товар на складе.

·>Я согласен, что это требует бОльших усилий. Но если изначально закладываться на МСА-подход и понятие workflow уже есть, это практически бесплатно.
·>А в случае если у нас был изначально монолит, то дело плохо, конечно. Распилить код, рассчитывающий на acid-транзакции ничем неограниченной сложности — очень трудозатратно.

·>Это уже шаг второй — как именно workflow будет реагировать на событие "item resevation failed" — инициировать отмену AoN или переходить в Partial Fill Negotiation.
Ну с моей точки зрения делить транзакцию на ещё более мелкие гранулы, чем по границам (микро)сервисов — уже оверкилл, если только это не обосновывается бизнес-необходимостью.
Кстати, современные маркетплейсы типа Озона, емнип, при оформлении заказа запросто делят его на части типа "это уже зарезервировали, а вот это внезапно кончилось — мы переложили его обратно в корзину. Сообщить вам, когда оно появится в продаже"?