Облачная СКУД для стадиона «Крылья Советов»: контроль доступа 45 000 болельщиков без интернета

Заказчик

Крупный спортивный объект — стадион «Крылья Советов» на 45 000 мест. В пиковые часы необходимо контролировать доступ десятков тысяч болельщиков, включая VIP-зоны, и отслеживать вход/выход

Задача

Разработать облачную платформу управления мероприятиями и билетами. Работает со стационарными СКУД и на площадках без инфраструктуры — через мобильные устройства.

Как мы за 4 месяца разработали облачную СКУД для стадиона на 45 000 мест — с офлайн-режимом и защитой от копий билетов

Вводная часть

Представьте день матча на стадионе «Крылья Советов». 45 000 болельщиков одновременно подходят ко входам. Контролёры вручную проверяют билеты — кто-то пытается пройти по копии, кто-то лезет в VIP-зону, где ему быть не положено. А если человек зашёл и вышел — никто не знает, вернулся он или нет. Очереди растут, персонал не успевает, аналитики нет.

Заказчик хотел не просто ускорить проход, а получить единую облачную платформу, которая:

• работает и со стационарными СКУД, и на площадках без инфраструктуры — через мобильные устройства;

• поддерживает офлайн-режим: сканирует билеты без сети, а потом синхронизируется;

• интегрируется с несколькими билетными системами;

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

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

Дедлайн — 4 месяца. Команда — небольшая: бэкендер, фронтенд, тестировщик, архитектор и менеджер.

Сложности и ограничения

Когда мы начали разбираться, выяснилось, что самое трудное — не написать систему контроля доступа, а заставить её работать в реальных условиях стадиона: без интернета, на слабых устройствах, при большом потоке людей.

1. Зависания интерфейса на Xiaomi. На небольших площадках система работала нормально. Но когда билетов в базе стало 45 000 — столько продаётся на один матч, — на устройствах Xiaomi начались зависания интерфейса. Конкретно при открытии клавиатуры: контролёр нажимает на поле ввода, а экран не отвечает секунду-две. На других Android-смартфонах и на iPhone такого не было.

2. Сервер не справлялся с запросами. Бэкенд не выдерживал объём. Мы использовали SQLAlchemy — удобный инструмент для работы с базой данных, но он создавал лишнюю нагрузку. Запросы выполнялись медленнее, чем могли бы.

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

4. Организационная сложность. Первый тестовый матч стал проверкой системы в реальных условиях. Полноценный прогон на большом потоке случился позже — так обычно и бывает, когда технология встречается с живыми процессами площадки.

Что мы сделали

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что здесь «тяжёлое», а что «лёгкое»:

Именно поэтому в тестах 200 RPS — это гарантированный порог на тяжёлых операциях, а 250 RPS — на лёгких.

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

Переход с 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 — нагрузочное тестирование

Архитектурное решение: единая кодовая база для нативного приложения и веб-версии. Приложение работает не только нативно, но и в браузере — Chrome, Firefox или Safari на телефоне. Кодовая база идентична, дублирования нет. Это важный плюс: не нужно поддерживать две версии.

Как мы работали

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

Типичный цикл:

1. Проектировали архитектуру и логику работы с офлайн-режимом.

2. Реализовывали клиентскую часть на Flutter, синхронизацию с бэкендом.

3. Тестировали на реальном оборудовании — мобильные устройства, ТСД.

4. Обнаруживали проблему (например, зависания на Xiaomi) — искали причину, исправляли.

5. Проводили нагрузочное тестирование: 50 000 билетов, 224 852 прохода за один прогон.

6. Выявляли узкие места — фиксировали и передавали в оптимизацию.

Разработчик: С технической точки зрения сложность была не в стеке, а в том, чтобы заставить систему работать в реальных условиях стадиона. При 45 000 билетов на устройствах Xiaomi начались зависания интерфейса — мы долго искали причину, но нашли: проблема была в отрисовке при открытии клавиатуры. Переход на SQLite + Drift решил вопрос полностью.

Результат

Система прошла тестовый прогон на реальном матче и запущена в работу.

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

• 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.

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

Бизнес-эффект:

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

• Видно, кто зашёл, куда и вышел ли.

• Аналитика загрузки секторов в реальном времени.

• Готовность к работе на объектах с большей вместимостью.

Отзыв разработчика:

«С технической точки зрения сложность была не в стеке, а в том, чтобы заставить систему работать в реальных условиях стадиона. При 45 000 билетов на устройствах Xiaomi начались зависания интерфейса — мы долго искали причину, но нашли: проблема была в отрисовке при открытии клавиатуры. Переход на SQLite + Drift решил вопрос полностью».

Перейти на сайт