Архитектура единого меню для сайта, приложения и киоска

Один бэкенд, а не три приложения с общим дизайном

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

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

case image — Один бэкенд обслуживает сайт, приложение, киоск и экраны в залах

Меню зависит от конкретного ресторана, а не от абстрактной сети

Ключевая сложность в том, что «меню сети» — это не единый статичный список. Один и тот же ресторан бренда в разных городах может продавать одно и то же блюдо по разным ценам; не в каждой точке есть, например, фритюр для жареных позиций, поэтому часть меню в одних ресторанах доступна, а в других — нет.

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

Один и тот же заказ — разный путь оплаты

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

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

Обсудим архитектуру единой платформы для вашей сети

Собираете сеть из нескольких каналов продаж и не хотите три параллельные системы?

Оценить проект

Чек-лист: что проверить перед добавлением нового канала

Когда к сайту и приложению добавляется киоск, экран в зале или любой новый канал, стоит явно сверить пять вещей:

Источник меню один. Новый канал не заводит собственную копию меню — он читает то же эталонное меню и те же связи с базами ресторанов, что и остальные каналы.
Доступность считается на уровне ресторана, а не сети. Логика «этого блюда нет в этой точке» должна работать одинаково во всех каналах, а не быть особенностью одного из них.
Оплата и сессия — под конкретный сценарий устройства. Общий бэкенд не означает одинаковый UX оплаты: для публичного устройства нужна своя логика очистки сессии.
Лояльность и промо не дублируются. Начисления и списания бонусов идут через общий модуль лояльности, а не через отдельную реализацию для нового канала.
Мониторинг общей логики важнее мониторинга канала. Раз баг в общем слое сразу проявляется во всех каналах, стоит закладывать это в тестирование нового канала — не только его собственный интерфейс, но и то, как он использует общие данные.

Что это даёт при масштабировании на новый канал

Когда сеть добавляет новый канал продаж — экран в зале ресторана, киоск на новой точке, — ему не нужно повторно решать задачи, которые уже решены на уровне платформы: где брать актуальное меню, как учитывать разные цены по городам, как забирать стоп-листы в реальном времени. Новый канал подключается к уже существующему бэкенду и с первого дня работает с той же логикой, что и остальные — тем самым новый канал продаж не превращается в отдельный ИТ-проект каждый раз заново.

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

С какого числа точек имеет смысл строить единый бэкенд, а не отдельные решения под каждый канал?

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

Что делать, если для киоска нужна логика, которой нет в приложении — например, локальный экран блокировки?

Такие вещи остаются на уровне интерфейса конкретного канала и не требуют изменений в общем бэкенде — правило в том, чтобы через общий слой шли данные и бизнес-правила, а не оформление конкретного устройства.

Может ли общий бэкенд стать узким местом при добавлении новых каналов?

Может, если в него закладывать логику, специфичную для одного канала. Поэтому важно с самого начала разделять то, что относится к данным и правилам (общий слой), и то, что относится к конкретному интерфейсу (канал).