Как заставить шлагбаум самому решать, кого пускать
Как заставить шлагбаум самому решать, кого пускать Браслет, CRM и middleware между ними. Архитектура и стек — без воды Браслет, CRM и middleware между ними. Показываю архитектуру и стек, на котором всё держится. браслет это rfid-метка, а не магия У каждого активного клиента браслет с RFID-меткой стандарта Mifare. Той же меткой он открывает шкафчик, проходит турникет, платит в баре. На въезде ставится RFID-считыватель, подключённый к контроллеру — «мозгу» шлагбаума, который командует приводом стрелы. Вся интеграция в одном предложении: уникальный номер метки с браслета сделать ключом ещё и от парковки. Носить и активировать клиенту ничего не надо. Браслет уже есть у 100% активных клиентов, новые носители раздавать не нужно. Инфраструктура, за которую заплачено, начинает работать ещё в одном месте. почему нельзя дёргать crm в момент проезда Кажется логичным: считыватель поймал метку, контроллер делает запрос в CRM, получает ответ «пускать или нет», поднимает стрелу. На бумаге красиво. На практике — это точка отказа. Любой сетевой запрос это задержка и зависимость. Моргнул интернет, лёг API, упал провайдер — и клиент стоит у стрелы, сзади очередь. Завязывать открытие шлагбаума на доступность внешнего сервиса нельзя. Поэтому архитектура обратная. Решение принимает сам контроллер — локально, по своему внутреннему списку разрешённых меток. Сверка занимает доли секунды и не требует сети. Как брелок в твоём ЖК: открывает по заранее внесённому списку, не звонит в управляющую компанию в момент нажатия. из чего собран мост между системами Между CRM и контроллером встаёт middleware — сервис на Python под systemd на Ubuntu-VPS. Его единственная задача — держать список меток в контроллере актуальным. Источник правды — CRM, тянем данные по REST API: кто активен, у кого живой абонемент, заморозка, тариф. Синхронизация — вебхуков у CRM нет, работаем поллингом. Раз в минуту опрашиваем API и забираем только изменившиеся записи по метке времени — не всю базу. Дёшево по трафику. Хранилище — SQLite: связка «UID метки ↔ ID клиента ↔ текущий флаг доступа», плюс журнал проездов. Лёгкая, без отдельного сервера БД. Объёмы крошечные — несколько тысяч меток. Меньше движущихся частей, проще бэкап. Запись в контроллер — выставляем каждой метке флаг доступа через его REST-API. Шлём только дельту, реально изменившиеся метки. Планировщик — ночная полная сверка по таймеру, логи в journalctl. Скучно и надёжно. три механизма синхронизации Самый частый страх: «человек купил карту днём, ему сразу на парковку, а у вас синхронизация раз в сутки». Закрыто тремя контурами. Первый — инкрементальный поллинг каждую минуту: оплата прошла, и в пределах минуты статус метки в контроллере становится разрешённым. Второй — ручная принудительная синхронизация: кнопка «выдать доступ сейчас» на ресепшн обновляет одну метку за пару секунд, если клиент уже стоит у въезда. Третий — ночная полная сверка: истёкший по дате абонемент не приходит событием, это просто наступившая дата. Раз в сутки система проходит по всей базе и гасит просроченные метки. Клиент ничего этого не видит. Он видит поднятую стрелу. В третьей части — что происходит, когда стрела открыта и как одна интеграция становится платформой для всего клуба. 👉 Телеграм: t.me/hudushin_seo 👉 MAX: max.ru/id623410360097_biz 👉 Речевая аналитика: slishnoai.ru #ХудушинМаксим #ZarubaFitness #ЗарубаФитнес #Подольск