Облачная СКУД для стадиона «Крылья Советов»

Разработать облачную платформу управления мероприятиями и билетами для стадиона «Крылья Советов» (около 45 000 мест). Система должна работать как со стационарными СКУД, так и на площадках без собственной инфраструктуры — через мобильные устройства. Требования: поддержка офлайн-режима, интеграция с несколькими билетными системами, аналитика потоков посетителей.

Проблема заказчика: легаси-системы не контролировали, кто и куда заходит. Люди проходили по копиям билетов, в том числе в VIP-зоны, куда им было нельзя. Отследить вход/выход и загрузку секторов было невозможно. Старая система была медленной и не давала никакой аналитики.

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

Срок: 4 месяца. Команда: один бэкендер, один фронтенд, тестировщик, архитектор и менеджер.

Команда АЙТИФОКС разработала облачную платформу управления мероприятиями и билетами для стадиона «Крылья Советов».

Ключевые компоненты:

• Облачная платформа на Python (бэкенд) — микросервисная архитектура, работа с PostgreSQL.

• Мобильное приложение и веб-версия на Flutter — единая кодовая база для нативного приложения и браузера.

• Мобильные сканеры и ТСД (терминалы сбора данных) — устройства, которые контролёры используют для проверки билетов на площадках без инфраструктуры. Работают на Android, iPhone (включая Safari) и в браузере.

• Интеграция с билетными системами — поддержка нескольких билетных ядер, возможность дообогащения данных.

• Офлайн-режим — работа без интернета с последующей синхронизацией.

• Аналитика — мониторинг загрузки площадок и потоков посетителей.

Как проходит билет: путь от сканирования до прохода

1. Сканирование. Контролёр считывает QR-код или штрих-код с телефона болельщика или с ТСД.

2. Валидация билета. Система проверяет: билет был выпущен, он продан, а не подделка, он ещё не проходил (защита от копий).

3. Проверка зоны доступа. Система смотрит, соответствует ли билет этому входу. Если билет в VIP-ложу, а человек стоит у обычного входа — контролёр увидит это на экране.

4. Регистрация прохода. Система фиксирует: билет прошёл, время входа, какое устройство сканировало.

5. Синхронизация. Данные о проходе уходят на сервер, а на устройство загружаются обновления.

Главные технические решения

Переход с Key Value Storage на SQLite + Drift. На небольших площадках система работала нормально. Но когда билетов в базе стало 45 000 — столько продаётся на один матч, — на устройствах Xiaomi начались зависания интерфейса, особенно при открытии клавиатуры. На других Android-смартфонах и на iPhone таких проблем не было.

Мы перепробовали разные варианты простых хранилищ — одни не работали в браузере, другие устарели. Тогда поставили на устройство полноценную базу данных SQLite + Drift для Flutter. Добавили миграции и индексы. Проблема ушла.

Оптимизация бэкенда. Когда билетов стало 45 000, сервер не справлялся с объёмом запросов. Причина была в SQLAlchemy — инструменте для работы с базой данных. Он удобный, но создавал лишнюю нагрузку. Мы разобрались, где теряется скорость, и частично заменили SQLAlchemy на прямые запросы к базе. Переработали индексы — ускорители поиска. После этого сервер стал держать нагрузку.

Офлайн-режим. Стадионы — это места, где интернет может «упасть» в самый неподходящий момент. Система должна работать без сети: сканировать билеты, регистрировать проходы, а потом синхронизироваться. В тестах мы загружали на клиент до 50 000 билетов — это тестовая нагрузка с запасом.

Отдельно мы продумали более жёсткий сценарий: большой стадион и полное отсутствие интернета. Архитектура позволяет работать без сети — данные загружаются на устройство заранее, проходы фиксируются локально, синхронизация идёт при появлении связи. Офлайн-режим протестирован отдельно: система корректно сканирует билеты и регистрирует проходы без сети, а при восстановлении связи синхронизируется с сервером.

Защита от копий билетов. Система обращается к билетному ядру, понимает, какие билеты были выпущены. Считывается штрих-код или QR-код с мобильного телефона или ТСД. Если билет уже прошёл — система не пустит, а если билет не соответствует входу (например, VIP-ложа) — контролёр увидит это на экране.

Какие инструменты использовали

• Python — бэкенд, микросервисная архитектура.

• Flutter — фронтенд для нативного приложения и веб-версии.

• SQLite + Drift — локальное хранилище на клиенте.

• PostgreSQL — основная база данных.

• gRPC — взаимодействие между клиентом и сервером.

• Yandex Tank + Pandora — нагрузочное тестирование.

АЙТИФОКС разработал и протестировал облачную СКУД для стадиона «Крылья Советов».

Что мы обеспечили:

• 50 000 билетов и 224 852 прохода за один тестовый прогон — искусственная нагрузка с запасом. Реальный стадион — 45 000 мест. Это в 2,5 раза больше, чем даёт один реальный матч (45 000 зрителей × 2 прохода = 90 000 проходов). Запас нужен, потому что стадион может принимать концерты и другие события, а система должна работать и на объектах с большей вместимостью.

• 2 400 проходов в минуту на тяжёлых операциях — этого достаточно, чтобы пропустить 45 000 зрителей за 30–40 минут.

• 200 RPS — гарантированный порог на самых тяжёлых операциях (проверка билета, синхронизация).

• 250 RPS — максимальная пропускная способность на лёгких операциях (подтверждено нагрузочным тестированием).

• 0 ошибок — на проверке билета и массовой регистрации проходов.

• Единая кодовая база — нативное приложение и веб-версия без дублирования.

• Офлайн-режим — работает без интернета, синхронизируется при восстановлении связи.

• Интеграция с билетными системами — поддержка нескольких ядер, дообогащение данных.

Нагрузочное тестирование:

Пояснение по нагрузке: 50 000 билетов и 224 852 прохода — тестовая база за один прогон. На один билет приходится 2–4 прохода (вход, выход, повторный вход). С учётом 5 запросов на один проход система держит 40 проходов в секунду — около 2 400 в минуту. На лёгких операциях (сканирование без синхронизации) — до 250 RPS.

Честно о зонах роста: отдельные стресс-тесты помогли выявить зоны роста. Мы зафиксировали их и продолжаем работать над оптимизацией.

Почему «простая» система контроля доступа оказалась непростой

Часто заказчики думают: «У нас есть билеты, нужно просто сканировать их на входе. Что тут сложного?» На деле именно в таких задачах всплывают главные риски: нагрузка на клиенте, офлайн-режим, интеграция с чужими системами.

В проекте для «Крыльев Советов» мы не просто написали приложение для сканирования. Мы:

• Решили проблему производительности на устройствах Xiaomi — перешли на SQLite + Drift.

• Оптимизировали бэкенд — отказались от части SQLAlchemy.

• Провели нагрузочное тестирование — нашли пределы и узкие места.

• Обеспечили работу без интернета — с синхронизацией при восстановлении связи.