Фальшивые билеты и VIP-зоны без контроля: как мы сделали СКУД для стадиона на 45 000 мест
Или история о том, как офлайн-режим и переход на SQLite + Drift превратили контроль доступа в управляемые потоки.
Представьте: стадион в день матча. Десятки тысяч болельщиков идут к входам. Контролёры вручную проверяют билеты — кто-то пытается пройти по копии, кто-то не на свой сектор. В VIP-зоны набиваются люди, которым там быть не положено. А если человек зашёл и вышел — никто не знает, вернулся он или нет. Старая система медленная, аналитики нет.
Заказчик хотел не просто «пускать по билетам», а управлять потоками: понимать, кто зашёл, куда, вышел ли, сколько людей в секторе. В реальном времени. И чтобы работало даже там, где нет стационарных турникетов и интернета.
За 4 месяца команда АЙТИФОКС сделала облачную СКУД. Сервер — на Python, приложение — на Flutter: одна кодовая база для телефона и браузера. Сначала MVP, потом тесты на реальной нагрузке. Когда билетов стало 45 000, на устройствах Xiaomi начали зависать клавиатуры, а сервер не справлялся с запросами. Перевели локальное хранилище на SQLite + Drift, ускорили бэкенд.
Не написать систему, а заставить её работать в реальных условиях стадиона.
Первое — объём данных. 45 000 билетов на клиенте, зависания интерфейса на Xiaomi. Перепробовали простые хранилища — не подошли: одни не работают в браузере, другие устарели. Поставили полноценную SQLite с Drift, добавили миграции и индексы.
Второе — офлайн. Стадион — место, где интернет может упасть в самый неподходящий момент. Сделали офлайн-валидацию: билеты загружаются заранее, проходы фиксируются локально, синхронизация — когда появляется связь. Отдельно протестировали сценарий «большой стадион + полное отсутствие интернета».
Третье — бэкенд. SQLAlchemy создавал лишнюю нагрузку. Частично заменили на прямые запросы к базе, переработали индексы. Сервер перестал задыхаться.
В нагрузочных тестах система обработала 50 000 билетов и 224 852 прохода за один прогон — это больше реальной вместимости стадиона (45 000) и в 2,5 раза больше, чем даёт один матч. Подтверждённый порог — 200 RPS на тяжёлых операциях, около 40 проходов/с. Ошибок — ноль.
Было: копии билетов проходили, VIP-зоны без контроля, аналитики нет.
Стало: система проверяет билет, зону и повторный проход; контролёр видит всё на экране; работает даже без интернета; данные о потоках — в реальном времени.
40 проходов/с для текущего конфига достаточно, но без запаса на пик. На стадионе с плотной пиковой нагрузкой и большим числом турникетов — как «Фишт» с его 108 турникетами на 43 000 мест — нужен другой потолок. Зафиксировали ориентир 140 проходов/с и продолжаем оптимизацию.
Опыт с офлайн-валидацией, локальной БД на клиенте и работой под реальную нагрузку пригодится везде, где контроль доступа нужно делать автономным: курорты, фестивали, транспорт, промышленные объекты.
Полный разбор кейса — с деталями архитектуры, нагрузочными тестами и таблицей результатов — читайте на сайте: https://itfox-web.ru/ru/cases/oblachnaia-skud-dlia-stadiona-krylia-sovetov-kak-my-sdelali-sistemu-ko?utm_source=teletype&utm_medium=article&utm_campaign=skud_case