Как связать r_keeper с мобильным приложением ресторана

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

Слои интеграции

Типовая схема: мобильное приложение → backend ресторана → адаптер r_keeper → POS и кухня. Backend хранит сессии, корзину, кеш меню и очередь повторных отправок.

На практике прямое обращение приложения к POS нежелательно: меняются протоколы, нужны retry и единая авторизация.

Компоненты

• сервис каталога (меню, цены, модификаторы);
• сервис заказов (создание, статусы, отмена);
• сервис доступности (стоп-листы);
• шина событий для push-уведомлений гостю.

Синхронизация меню и цен

Определите источник истины — обычно r_keeper. Задайте частоту полной синхронизации и инкрементальные обновления при изменении цены или состава. Маппинг ID между POS и приложением должен быть стабильным годами.

Контур заказа

Жизненный цикл: корзина → резерв/создание в r_keeper → подтверждение кухни → статусы «готовится / в пути / доставлен». Каждый переход — idempotent-операция с журналом, чтобы повтор запроса не создал дубликат.

На практике 2–3% заказов требуют ручной коррекции при сбое связи — заложите операторский контур.

Стоп-листы и модификаторы

Стоп может касаться блюда, размера, добавки или ингредиента. Адаптер должен переводить ограничения r_keeper в структуру каталога приложения. Задержка обновления — измеримый KPI, не «настройка на потом».

Оплата и фискализация

Онлайн-оплата может идти через эквайринг приложения с передачей признака оплаты в чек r_keeper, либо через сценарий оплаты на стороне POS — зависит от юридической схемы. Зафиксируйте, где формируется фискальный документ и кто master данных по чеку.

Отказоустойчивость и мониторинг

1. очередь повторной отправки заказов;
2. кеш меню с TTL и safe-mode при недоступности POS;
3. алерты: задержка стоп-листа, рост ошибок создания заказа;
4. сквозной trace-id от приложения до r_keeper.

Зафиксируйте контракт API: методы r_keeper, лимиты запросов, поведение при таймауте. Без этого фронт уйдёт вперёд интеграции и появятся ручные процессы на годы.

Staging должен повторять боевой: те же модификаторы, стоп-листы, типы оплаты. Упрощённый контур даёт ложную готовность за неделю до запуска.

Документируйте маппинг статусов: что в приложении значит «готовится», как это выглядит в r_keeper и на KDS. Расхождение статусов — частая причина звонков гостей.

Планируйте версионирование API: обновление r_keeper на точке не должно ломать приложение без controlled rollout. Feature flags и canary на одной локации снижают риск.

Security-контур: OAuth или token rotation, разделение прав read/write, аудит запросов с PII. Это особенно важно при нескольких подрядчиках на одном контуре.

Заложите нагрузочное тестирование: пиковый час с десятками параллельных корзин и созданием заказов. r_keeper и адаптер должны выдерживать burst без деградации KDS.

Опишите disaster recovery: резервный канал приёма заказов (колл-центр или упрощённая форма) на случай длительного outage интegrации.

Связанные страницы