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

S>·>Кстати, вовсе необязательно делать все строки заказа в одной БД-транзакции. Их можно делать поштучно или разбивать на батчи, шарды и т.п. с целью чтобы транзакции были меньшего размера. Это позволит сильнее параллелить и меньше крутиться на локах.
S>Как бы так ответить на простой тезис в сложном контексте...
S>Нулевое приближение: всё зависит от бизнес-задачи. Если партия сказала "есть контакт", то народ будет есть контакт. А если бизнес сказал "нам нужна атомарность", то разработчики будут есть атомарность. И вот как мы её обеспечиваем. "Я же не советую вам, сколько табов нужно ставить перед фигурной скобкой. Так и вы не учите меня торговать неликвидом".
S>И в обратную сторону: разработке похрену, сколько там покупателей отваливаются по таймауту в час пик, потому как "мы сделали всё, как в техзадании. Последствия — на вас".
S>В рамках этого подхода мы не имеем права произвольно менять постановку задачи. "Мы сделали всё, как вы сказали, только не миллион, а сто рублей, и не выиграл, а проиграл, и не атомарно, а частично, и не зарезервировал, а оплатил" и так далее. Надо уметь делать то, что требуется, а не то, что удобно.
Я не предлагаю менять постановку задачи, а менять реализацию. Если нам нужен AoN режим (all-or-nothing) мы просто реализуем откат зарезервированных позиций при отмене частично зарезервированного заказа.
Суть в том, что размер транзакции разумно ограничен, а не зависит от размера заказа.
Я согласен, что это требует бОльших усилий. Но если изначально закладываться на МСА-подход и понятие workflow уже есть, это практически бесплатно.
А в случае если у нас был изначально монолит, то дело плохо, конечно. Распилить код, рассчитывающий на acid-транзакции ничем неограниченной сложности — очень трудозатратно.

S>Первое приближение: общий успех достигается тогда, когда бизнес и разработка не пытаются прогнуть друг друга терминами "а это не мои проблемы", а совместно вырабатывают более хороший подход.
S>Например, частичное резервирование позволяет не послать покупателя нахрен потому, что какая-то не особо нужная ему фитюлина закончилась на складе, а пока он разбирался с тем, что именно и как надо выкинуть из корзины для завершения заказа, уже разобрали и то, что он точно хотел взять. И заодно это уменьшение гранулярности транзакций снижает lock contention и увеличивает общий throughput на том же железе.
S>Недостаток подхода — нужно тратить много усилий на торг и согласование требований.
Это уже шаг второй — как именно workflow будет реагировать на событие "item resevation failed" — инициировать отмену AoN или переходить в Partial Fill Negotiation.

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

S>·>Кстати, вовсе необязательно делать все строки заказа в одной БД-транзакции. Их можно делать поштучно или разбивать на батчи, шарды и т.п. с целью чтобы транзакции были меньшего размера. Это позволит сильнее параллелить и меньше крутиться на локах.
S>Как бы так ответить на простой тезис в сложном контексте...
S>Нулевое приближение: всё зависит от бизнес-задачи. Если партия сказала "есть контакт", то народ будет есть контакт. А если бизнес сказал "нам нужна атомарность", то разработчики будут есть атомарность. И вот как мы её обеспечиваем. "Я же не советую вам, сколько табов нужно ставить перед фигурной скобкой. Так и вы не учите меня торговать неликвидом".
S>И в обратную сторону: разработке похрену, сколько там покупателей отваливаются по таймауту в час пик, потому как "мы сделали всё, как в техзадании. Последствия — на вас".
S>В рамках этого подхода мы не имеем права произвольно менять постановку задачи. "Мы сделали всё, как вы сказали, только не миллион, а сто рублей, и не выиграл, а проиграл, и не атомарно, а частично, и не зарезервировал, а оплатил" и так далее. Надо уметь делать то, что требуется, а не то, что удобно.
Я не предлагаю менять постановку задачи, а менять реализацию. Если нам нужен AoN режим (all-or-nothing) мы просто реализуем откат зарезервированных позиций при отмене зарезервированного (частично или нет, неважно) заказа.
Суть в том, что размер транзакции разумно ограничен, а не зависит от размера заказа.
Я согласен, что это требует бОльших усилий. Но если изначально закладываться на МСА-подход и понятие workflow уже есть, это практически бесплатно.
А в случае если у нас был изначально монолит, то дело плохо, конечно. Распилить код, рассчитывающий на acid-транзакции ничем неограниченной сложности — очень трудозатратно.

S>Первое приближение: общий успех достигается тогда, когда бизнес и разработка не пытаются прогнуть друг друга терминами "а это не мои проблемы", а совместно вырабатывают более хороший подход.
S>Например, частичное резервирование позволяет не послать покупателя нахрен потому, что какая-то не особо нужная ему фитюлина закончилась на складе, а пока он разбирался с тем, что именно и как надо выкинуть из корзины для завершения заказа, уже разобрали и то, что он точно хотел взять. И заодно это уменьшение гранулярности транзакций снижает lock contention и увеличивает общий throughput на том же железе.
S>Недостаток подхода — нужно тратить много усилий на торг и согласование требований.
Это уже шаг второй — как именно workflow будет реагировать на событие "item resevation failed" — инициировать отмену AoN или переходить в Partial Fill Negotiation.