Два покупателя оплатили последний товар: как устроить резерв без гонки

На складе одна единица. Два человека почти одновременно открыли карточку, увидели наличие и оплатили. Ошибка не в том, что страница обновлялась раз в минуту. Даже совершенно свежая витрина не защищает от одновременного заказа: между чтением остатка и его изменением другой покупатель успевает сделать то же самое.

Остаток на складе и доступность для продажи — разные числа

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

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

Проверку и изменение надо сделать неделимыми

В реляционной базе один из вариантов — условно уменьшать доступное количество только при достаточном значении и проверять число затронутых строк. Другой — использовать подходящую блокировку в транзакции. Конкретная схема зависит от модели запасов; важно, чтобы две конкурентные операции не подтверждали одну и ту же единицу.

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

Каждый резерв связывается с заказом и имеет понятное состояние. Повтор запроса того же заказа не создаёт второй резерв. Освобождение тоже защищается от повтора: двойная отмена не должна дважды увеличивать доступное количество. Эти инварианты важнее выбора конкретного языка программирования.

Что делать с оплатой после истечения резерва

Платёж может подтвердиться позже ожидаемого срока. Поэтому правила оплаты и резерва проектируют вместе. После истечения система повторно проверяет возможность исполнения. Если товара уже нет, заказ направляется на согласование альтернативы или возврата по принятому регламенту. Автоматически обещать отгрузку только на основании позднего платежа нельзя.

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

Приёмка двумя конкурентными запросами

• Одна доступная единица, два одновременных новых заказа: подтверждается не больше одного резерва.
• Повтор подтверждённого заказа: остаток повторно не уменьшается.
• Повтор отмены: доступное количество восстанавливается один раз.
• Заказ с несколькими строками: отказ не оставляет неизвестных частичных резервов.
• Поздний платёж: выполняется предусмотренный процесс исключения, а не молчаливая отгрузка.

В интерактивной модели сравниваются наивная схема «оба прочитали старый остаток» и последовательная проверка с резервом. Она показывает механику гонки на целых единицах одного товара. Это не реализация складского учёта и не нагрузочный тест: реальный сервер здесь не вызывается.

Для магазина с действующей учётной системой сначала выясните, умеет ли её API подтверждать резерв атомарно. Если да, разумнее использовать этот контракт и надёжно обрабатывать неопределённый ответ, чем строить второй независимый склад на стороне сайта.