Как был выполнен перезапуск приложения Бургер Кинг

Решение

Любая высокотехнологичная система начинается с выбора фокуса. Фокусом стала возможность бизнеса реализовывать идеи, которые раньше были невозможны.

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

Ключевая идея решения

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

Что было сделано:

• спроектирована доменно-ориентированная сервисная архитектура: центральный монолит распилили на независимые сервисы (заказы, каталог, цены, платежи, лояльность, аналитика и другие);
• каждый сервис получил четкую зону ответственности и собственную базу данных;
• архитектура изначально допускает рост — новые домены добавляются без переписывания ядра. Итоговый бэкенд состоит из порядка 20 независимых сервисов.
• реализовано покрытие unit-тестами новых сервисов и внедрены автотесты любых изменений.
• добавлено непрерывное нагрузочное тестирование для обеспечения стабильности под высокой нагрузкой.

Этапы работ

Этап 1. Архитектурное проектирование и стратегия миграции

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

• заказы и корзина;
• каталог и рестораны;
• цены, конфигурации;
• пользователи и аутентификация;
• платежи и чеки;
• лояльность и CRM/CDP;
• уведомления, чат, отзывы;
• аналитика и экспорт данных.

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

Этап 2. Разработка ключевых доменных сервисов

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

Разработали backend ключевых сервисов:

• сервисы заказов и корзины с поддержкой сложной кастомизации;
• каталог продуктов и управление ресторанами;
• система цен и промо-механик;
• платежные интеграции.

Реализовали бизнес-логику совместно с аналитиками:

• перевели требования в работающие сценарии;
• проработали граничные случаи и исключения;
• обеспечили согласованность данных между сервисами.

Подготовили интеграции с внешними системами и партнерами.

Этап 3. Composition Layer и параллельная работа систем

Обеспечили возможность безопасной миграции — старый и новый бэкенд должны работать параллельно.

Спроектировали слой композиции (Composition Layer) для стандартизации и оптимизации взаимодействия между бэкендом и фронтендом:

• API Gateway;
• единая точка входа для мобильного приложения;
• маршрутизация запросов;
• прозрачность для пользователя;
• откат на старую систему в случае проблем.
• упрощение разработки backend-сервисов — изменения внутри сервисов не требуют доработок на фронтенде, если не меняется контракт. 

Этап 4. Тестирование и оптимизация производительности

Подготовили систему к реальной пользовательской нагрузке. Внедрили полное покрытие unit-тестами и автотесты для всех изменений. Провели нагрузочное тестирование с симуляцией трафика миллионов пользователей, нашли и устранили узкие места производительности. Настроили мониторинг, дашборды и алерты.

Провели нагрузочное тестирование:

• симуляция трафика миллионов пользователей;
• поиск узких мест производительности;
• оптимизация критических путей.

Настроили мониторинг и метрики:

• дашборды производительности;
• алерты на аномалии;
• сбор технических и продуктовых метрик.

Этап 5. Закрытое тестирование и подготовка к публичному релизу

Запустили новый бэкенд сначала на ограниченной аудитории (~100, ~1000 внутренних пользователей), затем постепенно увеличивали долю — с 1%, 5% до полной раскатки на 100% реальных пользователей. На каждом этапе отслеживали конверсионные и технические метрики, собирали обратную связь, исправляли проблемы. 

Внутреннее демо:

• показы новой системы стейкхолдерам;
• сбор первичной обратной связи.

Закрытое тестирование:

• первый запуск на ~100 и ~1000 пользователей (в основном внутренние сотрудники);
• мониторинг стабильности и производительности;
• сбор обратной связи и исправление критических проблем.

Подготовка к массовому релизу:

• постепенная раскатка с 1% до 5% пользователей с отслеживанием конверсионных и технических метрик;
• сбор отзывов из сторов и их обработка;
• при обнаружении проблем — остановка раскатки, исправление, продолжение;
• валидация всех критических сценариев;