География и её ограничения
Сеть, о которой идёт речь, работает в России, Казахстане и Беларуси; ранее была представлена в ОАЭ (франчайзи в этом регионе позже отключили от сети), рассматривается запуск в Узбекистане. Основная часть точек — в России. Это создаёт вполне конкретное техническое ограничение: устойчивость интернет-соединения и доступность внешних сервисов между разными странами присутствия — не одинаковы, и то, что стабильно работает в одном регионе, может работать заметно хуже или быть недоступным в другом. Эта разница ощущается уже на этапе разработки, а не только в эксплуатации.
Региональные инстансы вместо одной точки отказа
Архитектурное решение — не одна централизованная система, обслуживающая все страны из одной точки, а несколько копий (инстансов) приложения, каждая из которых обслуживает свой регион. Логика в том, чтобы пользователь в конкретной стране получал быстрый и стабильный отклик от инфраструктуры, физически и сетевым образом ближе к нему, — а не зависел от связи с сервером на другом конце света и от того, насколько хорошо тот сервер доступен именно из этой страны.
Дальше эти региональные инстансы сводятся в единое хранилище данных для аналитики по сети в целом — головная компания должна видеть общую картину продаж, лояльности, эффективности ресторанов вне зависимости от того, в какой стране находится конкретная точка, даже если оперативно каждый регион обслуживается собственной копией платформы.
Что варьируется по странам
Не вся бизнес-логика одинакова во всех регионах — часть настроек платформы сделана явно на уровне страны, а не единого глобального значения:
- валюта и, при необходимости, обменный курс для бонусов лояльности, если предусмотрен их пересчёт между регионами;
- максимальный процент оплаты заказа бонусами и условия реферальной программы — они могут отличаться по странам;
- условия welcome-бонуса и другие механики лояльности, о которых подробно рассказано в статье «Бесшовная миграция программы лояльности»;
- доступность конкретных внешних сервисов — например, интеграция с определённым сервисом доставки может быть доступна в одной стране и не быть доступна в другой из-за локальных ограничений или отсутствия партнёрства.
Технически конфигурация лояльности в платформе начинается именно с создания профиля страны — это отражает то, что мультирегиональность заложена не поверх готовой системы, а на уровне модели данных с самого начала.
Локальные зависимости, о которых легко забыть
Часть решений в архитектуре продиктована не бизнес-логикой, а рисками, специфичными для конкретного региона. Например, для карт в мобильном приложении команда написала собственную обёртку под Яндекс Карты для React Native — решение, связанное с неопределённостью в том, насколько долго и стабильно в регионе продолжит работать альтернативный картографический сервис. Такие решения нельзя предугадать заранее по одному только техническому заданию — они появляются по мере того, как команда сталкивается с конкретными ограничениями конкретного региона.
Чего не стоит недооценивать при запуске в новой стране
Опыт этого проекта показывает несколько пунктов, которые стоит проверить до, а не после запуска в очередной стране:
- Юридические лица и локальная фискализация. У каждой страны свои требования к чекам и платежам — это не техническая деталь, а условие, без которого точка не может легально принимать оплату.
- Устойчивость связи между регионом и остальной инфраструктурой. Стоит заранее проверить, как ведёт себя интеграция при деградации или временной потере связи с центральным хранилищем — региональный инстанс не должен переставать работать из-за того, что недоступна аналитика.
- Локальный список доступных партнёров по доставке и платежам. Сервис, который используется в одной стране, может быть недоступен или юридически невозможен в другой — это стоит сверить на этапе планирования, а не разработки.
- Перевод интерфейса и контента. Мультиязычность — отдельная задача, не совпадающая с мультирегиональностью: язык интерфейса и страна размещения ресторана не всегда совпадают один к одному.
