Пропуск в фитнес-клуб по QR: турникет вместо ресепшена
Приложение с регистрацией и цифровым пропуском. Турникет сканирует QR и открывается сам, если абонемент действует. Администратор на входе больше не нужен, а все посещения остаются в системе.
С чего начинали
До внедрения вход держался на человеке за стойкой, и это ограничивало клуб по трём фронтам.
Очередь в час пик
Администратор вручную искал клиента в списке, проверял срок абонемента и только потом открывал проход. В вечерний пик у стойки собирались люди.
Человеческий фактор
Проверка «на глаз»: знакомого пропускали, чужой абонемент проходил, заморозку и лимит посещений никто не отслеживал.
Нет данных
Посещаемость не фиксировалась. Нельзя было понять загрузку по часам, долю непродливших и кто вообще перестал ходить.
Как это работает
Пять шагов от установки приложения до открытого турникета. Ни одного человека в цепочке.
Регистрация в приложении
Клиент создаёт аккаунт по номеру телефона, заполняет профиль. Аккаунт привязывается к карточке клиента в клубе.
КлиентЦифровой пропуск
В приложении появляется QR-код. Он короткоживущий и обновляется сам, поэтому скриншот, отправленный другу, быстро становится бесполезным.
ПриложениеСканирование на турникете
Сканер читает код и отправляет его на сервер. Сервер проверяет подпись и срок действия кода, а не только картинку.
Турникет → APIПроверка права прохода
Проверяются абонемент, его срок, заморозка, лимит посещений и блокировки. Решение принимает сервер, а не приложение и не сканер.
APIОткрытие и запись
Турникет открывается, событие уходит в журнал: кто, когда, какое решение и почему. Отказ тоже пишется, с причиной.
Турникет + БДАрхитектура
Логика проверки живёт в одном месте. Приложение и турникет — только клиенты, им нельзя доверять решение.
QR-пропуск, история
выдача и подпись QR,
журнал событий
открытие, отказ
Что сделал
От схемы данных до инструкции, по которой клуб работает без меня.
- Спроектировал схему данных: клиент, абонемент, заморозка, посещение, устройство, событие прохода
- Сделал регистрацию и вход по номеру телефона, привязку аккаунта к карточке клиента
- Реализовал цифровой пропуск: подписанный QR с коротким сроком жизни и автообновлением
- Написал серверную проверку права прохода: срок, заморозка, лимит, блокировка
- Связал сканер турникета с API: запрос на проход, ответ «открыть» или «отказ с причиной»
- Сделал журнал: каждое сканирование пишется, включая отказы
- Добавил идемпотентность: повторное сканирование не открывает второй проход и не дублирует запись
- Предусмотрел работу без сети: если API недоступен, турникет работает по локальному списку и отправляет события после восстановления
- Собрал админку: продления, заморозки, ручной пропуск с обязательным комментарием
- Сделал отчёты по загрузке зала и отказам в доступе
- Написал инструкцию для клуба: что делать, если клиент не проходит, где смотреть журнал
Что могло сломаться и что с этим сделано
Это половина работы. Пропускная система живёт не в идеальных условиях.
Стек
Серверная логика на Java, клиент — веб-приложение, обмен через API.
Результат
Проход перестал быть услугой человека и стал функцией системы.
Отдельный эффект: клуб перестал спорить с клиентами о том, был проход или нет. Есть событие с временем и устройством — разговор заканчивается.
Что я делал в проекте
Роль целиком: от разбора процесса до запуска и инструкции.
Анализ
Разобрал, как проходит вход сейчас, где теряются данные и какие проверки обязательны. Собрал требования и схему данных.
Разработка
Серверная логика проверки права прохода, выдача и подпись QR, связка со сканером турникета, админка и отчёты.
Запуск
Настройка сценариев отказа, работа без сети, журнал и инструкция для сотрудников клуба.