Цель — спроектировать систему управления нагрузкой на сайт/приложение Ticketon в момент старта продаж на массовые события, которая исключает падение сервиса и даёт пользователям прозрачное и справедливое место в очереди, вместо бесконтрольного наплыва запросов на backend. Участник проектирует архитектуру «зала ожидания» (waiting room) перед стартом продаж, правила распределения мест в очереди, механизм защиты от накрутки позиции в очереди (множественные вкладки/аккаунты), а также стратегию деградации сервиса при экстремальной нагрузке (что показывать пользователю, какие функции временно отключать). Существующий процесс старта продаж может быть перепроектирован полностью. Результат — проектный документ: архитектура, workflow, логика защиты очереди от накрутки, обоснование trade-offs. Код не требуется. Пилот / MVP Решение может быть внедрено поэтапно, участник сам предлагает объём пилота. Рекомендуемый путь: сначала запустить зал ожидания в «мягком» режиме — без строгой защиты от накрутки — на событии среднего спроса, проверить базовую механику очереди и собрать метрики нагрузки; затем включить защиту от накрутки позиции и стратегию деградации и обкатать на событии с более высоким спросом; полный охват (включая топовые события с 15–20-кратной нагрузкой) — после подтверждения, что честная очередь не ломается под пиком. Критерий перехода между этапами участник формулирует сам как часть решения. Источники данных Для проектирования доступны (как гипотетическая модель данных, без выгрузки реального production): исторические данные о нагрузке на прошлых стартах продаж (количество запросов в секунду по времени, доля ошибок 5xx/таймаутов, время от старта продаж до исчерпания билетов); данные об инвентаре билетов/мест (сколько доступно, как быстро раскупается по категориям); профиль и сессия пользователя (аккаунт, устройство/app-инстанс, IP); логи CDN/edge-слоя о входящем трафике перед бэкендом. Участник указывает, какие источники использует и какие допущения делает там, где данных не хватает. Необходимые интеграции Решение должно описывать точки интеграции с существующими системами: CDN/edge-слой или балансировщик (точка, где трафик впервые перехватывается в очередь, до бэкенда); сервис аутентификации/аккаунтов (для привязки места в очереди к пользователю, а не к вкладке); сервис инвентаря билетов (сколько мест реально доступно, чтобы синхронизировать скорость впуска из очереди с наличием билетов); платёжный шлюз (учитывая, что именно на этапе оплаты сейчас фиксируются таймауты); канал уведомления пользователя о его очереди (push/веб-сокет/SMS — какой выбрать и почему). Отдельно — обоснованный выбор: использовать готовый anti-bot/device-fingerprinting провайдер для защиты от накрутки или строить эту логику самостоятельно (build vs buy). Также в объём входит интеграция с системой мониторинга нагрузки (метрики RPS, ошибок, времени в очереди) для оперативного реагирования.

Цена договорная