Как спроектировать бронирование мест так, чтобы не было двойных броней?

Место — ресурс в единственном экземпляре, поэтому вся задача сводится к корректному переводу его из «свободно» в «занято» при десятках одновременных попыток. Рабочая схема — условное обновление в одной транзакции: UPDATE ... WHERE status = 'free', и кто изменил строку, тот и забронировал; проигравшие получают отказ мгновенно, без ожидания блокировки. Уникальный индекс на пару «событие + место» остаётся последним рубежом на случай ошибки в коде. Оплата занимает минуты, поэтому место сначала резервируется с TTL, и просроченные резервы возвращает в продажу фоновая задача. Главный компромисс — длина резерва: короткий раздражает покупателей, длинный делает зал занятым при нулевых продажах.