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

1. Вводная задача от заказчика, проблематика, цели

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

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

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

Ключевые ограничения проекта:

· Нестабильные условия на площадке. Стадион — это место, где интернет может «упасть» в самый неподходящий момент. Система должна работать без сети.

· Слабые устройства. Контролёры используют разные телефоны и ТСД — не самые мощные.

· Большой поток. Пик входа приходится на последние 30–40 минут перед матчем.

· Жёсткие сроки. Проект — 4 месяца.

· Ограниченные ресурсы. Команда: один бэкендер, один фронтенд, тестировщик, архитектор и менеджер.

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

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Команда АЙТИФОКС разработала облачную СКУД на Python (бэкенд) и Flutter (приложение и веб-версия — единая кодовая база).

Ключевые технические решения:

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

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

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

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

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

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

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

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

3. Проверка зоны доступа. Система смотрит, соответствует ли билет этому входу.

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

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

Стек технологий:

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

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

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

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

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

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

Как мы работали. Проект занял около 4 месяцев. Типичный цикл: проектировали архитектуру и логику офлайн-режима → реализовывали клиентскую часть на Flutter → тестировали на реальном оборудовании → обнаруживали проблему (например, зависания на Xiaomi) и исправляли → проводили нагрузочное тестирование → выявляли узкие места и передавали в оптимизацию.

3. Результаты сотрудничества

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

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

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

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

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

· 250 RPS — максимальная пропускная способность на лёгких операциях.

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

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

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

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

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

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

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

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

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

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

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