Облачная СКУД для стадиона на 45 000 мест: офлайн-режим, защита от копий билетов и 224 852 прохода в тестах

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

Стадион «Крылья Советов» на 45 000 мест не контролировал, кто и куда заходит: люди проходили по копиям билетов, в том числе в VIP-зоны, а отследить вход/выход и загрузку секторов было невозможно. За 4 месяца мы разработали облачную СКУД, которая работает и со стационарными турникетами, и автономно — через мобильные устройства контролёров. Ключевые вызовы: офлайн-режим (система сканирует и регистрирует проходы без интернета, синхронизируясь при восстановлении связи), защита от копий (валидация билета в билетном ядре с проверкой зоны доступа) и нагрузка (тестовый прогон: 50 000 билетов и 224 852 прохода, 200 RPS на тяжёлых операциях, 100% успешных проверок). В результате стадион получил управляемую систему с аналитикой потоков и защитой от копий.

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

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

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

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

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

Решение: облачная СКУД на Python (микросервисы, PostgreSQL), клиент на Flutter с единой кодовой базой для нативного приложения и браузера, локальное хранилище SQLite + Drift для офлайн-режима, интеграция с несколькими билетными системами через единый интерфейс.

Результат: система прошла тестовый прогон на реальном матче. Подтверждённая скорость — около 40 проходов/с на тяжёлых операциях, целевой пиковый ориентир — 140 проходов/с (8 400/мин). Защита от копий работает, аналитика потоков доступна, офлайн-режим протестирован отдельно.

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

Ключевая инженерная задача — заставить СКУД работать в реальных условиях стадиона: без интернета, на слабых устройствах, при потоке в десятки тысяч людей.

Что именно сделали:

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

Переход с Key Value Storage на SQLite + Drift: при 45 000 билетов на устройствах Xiaomi начались зависания интерфейса (особенно при открытии клавиатуры). Полноценная локальная БД с миграциями и индексами решила проблему; система стабильно работает с тестовой базой до 50 000 билетов.

Оптимизация бэкенда: SQLAlchemy создавал лишнюю нагрузку. Частично заменили его на прямые запросы, переработали индексы — сервер стал держать нагрузку.

Единая кодовая база на Flutter для нативного приложения и веб-версии (Chrome, Firefox, Safari) — без дублирования и поддержки двух версий.

Защита от копий: система обращается к билетному ядру, проверяет выпуск, продажу, факт предыдущего прохода и соответствие зоны доступа; при несоответствии контролёр видит это на экране.

Система прошла нагрузочное тестирование (Yandex Tank + Pandora) и подтвердила рабочие пороги: 200 RPS на тяжёлых операциях и 224 852 прохода за прогон.

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

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

Гипотеза. Если сделать ставку на локальную базу данных на устройстве и офлайн-валидацию, система выдержит не только текущий стадион, но и более крупные объекты — концерты, другие площадки.

Проверка. Сначала выпустили MVP, протестировали на реальной нагрузке и нашли узкие места: при 45 000 билетов зависали Xiaomi, сервер не справлялся. Перевели хранилище на SQLite + Drift, оптимизировали бэкенд. Затем — нагрузочный тест: 50 000 билетов и 224 852 прохода за один прогон (это в 2,5 раза больше реального матча, где 45 000 зрителей дают около 90 000 проходов).

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

Скриншоты