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

В теории это выглядит элегантно и современно. Но в реальности почти на каждом крупном событии возникает один и тот же эффект: система начинает зависеть от тысяч устройств, которые никто не контролирует.

На площадке оказываются тысячи смартфонов с разными версиями операционных систем, с разным уровнем батареи, с разной скоростью интернета. Wi-Fi сеть должна обслужить тысячи соединений одновременно. Даже хорошая корпоративная точка доступа редко справляется более чем с несколькими сотнями активных клиентов. Мобильные сети работают примерно так же: каждая базовая станция рассчитана на определённое число одновременных подключений, и когда плотность устройств превышает этот предел, сеть начинает деградировать.

В такие моменты начинается знакомая картина: приложение не загружается, QR-коды не сканируются, данные уходят с задержкой, а организаторы пытаются понять, что именно пошло не так.

Проблема в том, что система мероприятия оказывается завязана на самый непредсказуемый элемент инфраструктуры — личные телефоны участников.

Есть другой подход, который используют в инженерных системах, где важна устойчивость. Он начинается с простого вопроса: если невозможно стабильно подключить тысячу устройств, нужно ли вообще пытаться это делать?

Вместо модели, где каждый участник взаимодействует с системой напрямую, можно построить архитектуру, где взаимодействие происходит через ограниченное число операторов. Это хостес, координаторы активностей, сотрудники регистрации, операторы зон. Они работают с приложением и фиксируют действия участников.

Участник при этом может вообще не доставать телефон. Он приходит на активность, проходит через точку регистрации или участвует в задании — а система фиксирует это через сотрудника площадки.
Количество устройств, взаимодействующих с системой, резко уменьшается. Вместо тысячи телефонов остаётся двадцать, тридцать или пятьдесят рабочих устройств персонала. И именно это изменение архитектуры радикально повышает устойчивость всей системы.

Этот принцип лежит в основе системы Deep Tracking. Она изначально создавалась для мероприятий, где участники постоянно перемещаются между зонами, заняты активностями и не готовы дисциплинированно взаимодействовать с приложением.

В такой среде гораздо надёжнее, когда сканирует не участник, а сотрудник площадки.

Участник проходит через точку активности, и оператор сканирует его бейдж. Система фиксирует посещение зоны, участие в активности, переход по маршруту, начисление баллов или присутствие на сессии. Всё это происходит без участия смартфона гостя.

Фактически участник становится объектом инфраструктуры, а не её оператором. Это похоже на работу аэропортов или стадионов, где пассажиры и зрители не управляют системой контроля — система просто фиксирует их прохождение через точки инфраструктуры.

Главное инженерное преимущество такой модели — резкое сокращение количества подключений.
Когда тысяча участников одновременно открывает приложение, это тысяча сетевых соединений, тысячи запросов к серверу и огромный поток данных. Даже мощная инфраструктура начинает испытывать нагрузку.
Когда работают только устройства операторов, поток событий уменьшается на порядки. Система передаёт лишь события сканирования и обновления состояния. Для сети это несравнимо более лёгкая нагрузка.
Кроме того, рабочие устройства проще контролировать. Их можно заранее настроить, проверить, подключить к стабильной сети или к выделенному каналу. Если нужно, можно даже построить локальную сеть внутри площадки. Сделать это для двадцати устройств значительно проще, чем для двух тысяч.

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

Второй вариант — использование стационарных точек подключения. Хостес на регистрации, в зоне активностей или в штабе могут работать через стационарный Wi-Fi или проводную сеть. Подобная схема давно используется в аэропортах, гостиницах и билетных системах.

Есть и третий режим, который делает систему ещё устойчивее. Он основан на пакетной синхронизации данных. Устройство оператора может сохранять события локально, а затем передавать их в центральную систему при появлении соединения. Это означает, что даже временные перебои со связью не останавливают работу. Сканирование продолжается, а данные синхронизируются чуть позже.

Такой подход давно применяется в POS-терминалах, складских системах и системах инвентаризации. Там тоже важно, чтобы процесс не останавливался из-за кратковременных проблем со связью.

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

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

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

Поэтому устойчивые цифровые механики для мероприятий обычно строятся на трёх уровнях.

1. Сценарий события работает даже без интернета.
2. Взаимодействие с системой происходит через ограниченное число управляемых устройств.
3. А данные могут синхронизироваться пакетами, а не обязательно в реальном времени.

В такой архитектуре интернет становится не условием работы системы, а лишь ускорителем обмена данными.

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

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