Продажа билетов и запись: места достаются людям, а не ботам

Первая минута продаж

Нагрузка на билетный сервис устроена иначе, чем у магазина: весь день тихо, а в объявленное время тысячи людей одновременно обновляют страницу события и открывают схему зала. Самые тяжёлые запросы — получение свободных мест (/api/events/{id}/seats) и бронь (/api/reserve): каждое обращение затрагивает базу и блокировки мест. Именно их и бьют боты, причём не флудом, а точными запросами в первые секунды.

Почерк перекупщика

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

Подробнее о приёмах — в разделе о скальпинге и бронировании ботами.

Порядок настройки перед стартом

1. Включить кэш на странице события и афише, чтобы обновления страницы не доходили до сервера.
2. Поставить очередь ожидания перед схемой зала: посетитель получает место в очереди, а не участвует в гонке запросов.
3. Включить проверку браузера до входа в очередь, а не после.
4. Ограничить число билетов на покупателя, устройство и способ оплаты.
5. Сократить время брони без оплаты, чтобы места не простаивали в руках ботов.

Что сломается, если перестараться

• Уведомления эквайринга. Без исключения для адресов платёжного шлюза оплаченные заказы зависнут в статусе «ожидает оплаты».
• Виджеты продаж на сайтах организаторов. Встроенный виджет открывается в iframe на чужом домене, и правила проверки должны это учитывать.
• Контроль на входе. Сканеры билетов обращаются к API проверки; блокировка их запросов в день события остановит очередь у дверей.

Те же принципы работают для записи на приём, бронирования столиков и слотов, где количество мест ограничено.