где могут адекватно рассказать.
Недавно проходил собес и задали примерно следующий вопрос, как бы вы ответили?
Вопрос:
Берем интернет-магазин, оформление заказа, прям кнопку оформить заказ. Что нужно сделать на фронте и бекенде чтобы обеспечить идемпотентность запроса на создание заказа? (Например человек кликает 5 раз на кнопку, а у магазина нет столько товара или у человека нет столько денег на счету ну или что-угодно, что может сделать операцию «невозможной» с точки зрения бизнеса.
это на какую позицию такое спрашивают - джун, мидл, сеньор?
Трейни скорее всего
Очевидно, что не надо давать ему кликать 5 раз на кнопку. Остатки можно проверить еще до оформления, на предыдущем шаге. Товара нет - заказ не оформим Если первично все ок - заказ оформили и сразу отдали ему инфу, а не слать в одном потоке почту, смс и прочее . Пользователь смотрит и не понимает - оно оформилось или нет. Потом заказ в неком статусе - не оплачен или новый. Далее формируете счет на оплату и вперед. Бывают еще вариации, что без оплаты заказ не оформляется, но там чуть иначе процесс идет. Как экваер прислал подтверждение - тогда заказ меняет статус и заказ пошел в работу.
На любую, от проекта зависит. Конкурентная среда.
Во-первых, на запрос нужно навесить shared lock чтобы следующие запросы ждали очередь. Во-вторых, при клике добавлять товар в корзину. В-третьих, при оформлении заказа проверять по таблице остатков есть ли необходимое для заказа количество и если да, блокировать запись до окончания заказа
Если заблокировать на изменения остатки, то как другие купят или склад обновит ее , если продажа была оффлайн ?
Если офлайн продажа не выгружает "здесь и сейчас" данные в основную базу, то расхождений количества никак не избежать. А если выгружает, то оффлайн должен блокировать запись при выполнении операции если он первым туда ломанулся.
на какое время блокировать ? А если клиентов 10 оформляют ? - остальные будут ждать , пока блокировка снимется ?
Ровно на то время пока первый не закончит оформление. В это время также лучше включить пересчёт остатков, т.к. всё должно выполняться в транзакции, но часто эти механики разделяют друг от друга.
Да, будут сидеть и смотреть на бегунок с надписью "подождите, идёт оформление заказа" или что-то типа того
https://laravel.com/docs/10.x/queries#pessimistic-locking
А блокировать должна транзакция в которой все это дело выполняется, транзакция по оформлению заказа, верно?
Транзакция осуществляет защиту целостности данных. Блокировать должен shared lock на запросе. По-другому ещё его называют "пессимистичная блокировка". Выше линку скинул на доку.
Обсуждают сегодня