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

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

S>>Если не находит, то делает
·>

S>>begin transaction;
·>update stock 
·>...
·>update stock 
·>...
S>>insert into reservationItems(orderId, productId, quantity) values(42, 17, 10);
S>>insert into reservationItems(orderId, productId, quantity) values(42, 5, 1);
·>...
S>>commit transaction
·>

·>Кстати, вовсе необязательно делать все строки заказа в одной БД-транзакции. Их можно делать поштучно или разбивать на батчи, шарды и т.п. с целью чтобы транзакции были меньшего размера. Это позволит сильнее параллелить и меньше крутиться на локах.

Как бы так ответить на простой тезис в сложном контексте...

Нулевое приближение: всё зависит от бизнес-задачи. Если партия сказала "есть контакт", то народ будет есть контакт. А если бизнес сказал "нам нужна атомарность", то разработчики будут есть атомарность. И вот как мы её обеспечиваем. "Я же не советую вам, сколько табов нужно ставить перед фигурной скобкой. Так и вы не учите меня торговать неликвидом".

И в обратную сторону: разработке похрену, сколько там покупателей отваливаются по таймауту в час пик, потому как "мы сделали всё, как в техзадании. Последствия — на вас".

В рамках этого подхода мы не имеем права произвольно менять постановку задачи. "Мы сделали всё, как вы сказали, только не миллион, а сто рублей, и не выиграл, а проиграл, и не атомарно, а частично, и не зарезервировал, а оплатил" и так далее. Надо уметь делать то, что требуется, а не то, что удобно.

Недостатки подхода понятны.

Поэтому
Первое приближение: общий успех достигается тогда, когда бизнес и разработка не пытаются прогнуть друг друга терминами "а это не мои проблемы", а совместно вырабатывают более хороший подход.
Например, частичное резервирование позволяет не послать покупателя нахрен потому, что какая-то не особо нужная ему фитюлина закончилась на складе, а пока он разбирался с тем, что именно и как надо выкинуть из корзины для завершения заказа, уже разобрали и то, что он точно хотел взять. И заодно это уменьшение гранулярности транзакций снижает lock contention и увеличивает общий throughput на том же железе.
Недостаток подхода — нужно тратить много усилий на торг и согласование требований.

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