Разработка облачной СКУД для стадиона «Крылья Советов» с офлайн-режимом и защитой от копий билетов

Главное о кейсе

Заказчик — крупный спортивный объект, стадион «Крылья Советов» на 45 000 мест. В день матча десятки тысяч болельщиков одновременно подходят ко входам. Контролёры вручную проверяют билеты, кто-то пытается пройти по копии, кто-то лезет в VIP-зону, где ему быть не положено. Отследить вход/выход и загрузку секторов невозможно. Легаси-системы не контролировали, кто и куда заходит.
Задача — разработать облачную платформу управления мероприятиями и билетами, которая работает как со стационарными СКУД, так и на площадках без инфраструктуры — через мобильные устройства. Требования: офлайн-режим, интеграция с несколькими билетными системами, аналитика потоков посетителей.
Ключевые ограничения:
· при 45 000 билетов на устройствах Xiaomi зависал интерфейс при открытии клавиатуры;
· бэкенд не справлялся с объёмом запросов — SQLAlchemy создавал лишнюю нагрузку;
· нужен офлайн-режим — интернет на стадионе может «упасть» в любой момент;
· дедлайн — 4 месяца;
· команда — бэкендер, фронтенд, тестировщик, архитектор, менеджер.
Разработана облачная СКУД на Python и Flutter с единой кодовой базой для Android, iPhone и браузера. Перевели хранилище с Key Value Storage на SQLite + Drift, добавили миграции и индексы. Частично отказались от SQLAlchemy в пользу прямых запросов. Реализовали офлайн-валидацию: данные загружаются заранее, проходы фиксируются локально, синхронизация идёт при появлении связи. Защита от копий билетов через билетное ядро.
В тестах система обработала 50 000 билетов и 224 852 прохода за один прогон — в 2,5 раза больше, чем даёт реальный матч. Держит 200 RPS на тяжёлых операциях (проверка билета, синхронизация) и до 250 RPS на лёгких. 0 ошибок на проверке билета и массовой регистрации проходов. Система прошла тестовый прогон на реальном матче и запущена в работу.

Как проект изменил жизнь пользователей

Болельщики больше не стоят в длинных очередях на входе — система пропускает 2 400 человек в минуту, 45 000 зрителей заходят за 30–40 минут. Контролёры получили инструмент, который сам проверяет билет, защищает от копий и подсказывает, соответствует ли билет этому входу. Если билет в VIP-ложу, а человек стоит у обычного входа — контролёр увидит это на экране.
Система работает без интернета: если сеть на стадионе «упадёт», контролёры продолжат сканировать билеты и регистрировать проходы, а данные синхронизируются, когда связь появится. Это снимает зависимость от нестабильного соединения в пиковые часы.
Служба безопасности и организаторы получили аналитику в реальном времени: кто зашёл, куда, вышел ли, сколько людей в каждом секторе. Раньше этой информации не было вообще — теперь можно управлять потоками и видеть загрузку площадки.

Бизнес-задача и ее решение

Бизнес-задача: контролировать доступ десятков тысяч болельщиков на стадион, включая VIP-зоны. Защитить от копий билетов. Отслеживать вход/выход и загрузку секторов в реальном времени. Обеспечить работу на площадках без стационарных турникетов — через мобильные устройства.
Решение: облачная СКУД на Python (бэкенд) и Flutter (приложение и веб-версия — единая кодовая база). Переход на SQLite + Drift для стабильной работы при 45 000 билетов. Оптимизация бэкенда — частичный отказ от SQLAlchemy. Офлайн-валидация с синхронизацией при восстановлении связи. Интеграция с билетными системами через единый интерфейс.
Эффект: система прошла тестовый прогон на реальном матче. 50 000 билетов и 224 852 прохода за один тестовый прогон. 2 400 проходов в минуту — 45 000 зрителей заходят за 30–40 минут. 0 ошибок на проверке билета. Единая кодовая база для Android, iPhone и браузера. Готовность к работе на объектах с большей вместимостью.

Крафт (мастерство), реализация, технические детали

Стек: Python, Flutter, SQLite + Drift, PostgreSQL, gRPC, Yandex Tank + Pandora.
Ключевые решения:
1. Переход на SQLite + Drift. При 45 000 билетов на устройствах Xiaomi зависал интерфейс — особенно при открытии клавиатуры. Перепробовали разные Key Value Storage: одни не работали в браузере, другие устарели. Поставили полноценную базу данных SQLite + Drift для Flutter, добавили миграции и индексы. Проблема ушла.
2. Оптимизация бэкенда. SQLAlchemy создавал лишнюю нагрузку — запросы шли медленнее, чем могли бы. Разобрались, где теряется скорость, и частично заменили SQLAlchemy на прямые запросы к базе. Переработали индексы. Сервер стал держать нагрузку.
3. Офлайн-режим. Данные загружаются на устройство заранее, проходы фиксируются локально, синхронизация идёт при появлении связи. В тестах загружали до 50 000 билетов на клиент. Отдельно продумали жёсткий сценарий: большой стадион и полное отсутствие интернета.
4. Единая кодовая база. Приложение работает нативно на Android и iPhone, а также в браузере — Chrome, Firefox, Safari. Код идентичен, дублирования нет.
5. Защита от копий билетов. Система обращается к билетному ядру, понимает, какие билеты выпущены. Считывается штрих-код или QR-код. Если билет уже прошёл — система не пустит. Если билет не соответствует входу — контролёр увидит это на экране.
6. Путь билета. Сканирование → валидация (выпущен, продан, не проходил) → проверка зоны доступа → регистрация прохода → синхронизация.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Главный инсайт: самое трудное — не написать систему контроля доступа, а заставить её работать в реальных условиях стадиона: без интернета, на слабых устройствах, при большом потоке. «Очевидные» решения на тестовых данных разваливались в реальности — например, простое хранилище не тянуло 45 000 билетов, а SQLAlchemy тормозил запросы.
Проверенные гипотезы:
· Хранилище. Key Value Storage не подходит для больших объёмов и веба. SQLite + Drift решает проблему полностью.
· Бэкенд. SQLAlchemy создаёт оверхед — прямые запросы работают быстрее.
· Офлайн. Данные нужно загружать заранее и фиксировать проходы локально — синхронизация при появлении связи.
· Устройства. Проблема с зависаниями была только на Xiaomi. На iPhone и других Android-смартфонах всё работало нормально.
Процесс: 4 месяца, команда из пяти человек. Цикл: проектирование архитектуры → реализация на Flutter → тестирование на реальном оборудовании → обнаружение проблемы (например, зависания на Xiaomi) → исправление → нагрузочное тестирование → выявление узких мест. Выпустили MVP, протестировали на реальных данных, нашли узкие места и оптимизировали.
Коммуникация: заказчик не имел чёткого регламента по приёмке. Всё собирали по кусочкам: гипотезы, обсуждения, проверка на данных. Первый тестовый матч стал проверкой системы в реальных условиях — полноценный прогон на большом потоке случился позже. Это нормальный этап внедрения, когда технология встречается с живыми процессами площадки.

Скриншоты