Перезапуск приложения Бургер Кинг: новые фичи для пользователей, стабильность 99,95% и +7% к выручке через мобильный канал

Мобильное приложение Бургер Кинг — один из ключевых каналов продаж крупнейшей сети ресторанов быстрого питания в России. Оно входит в топ App Store и Google Play, обслуживает свыше 1 млн пользователей в день и генерирует прямую выручку, лояльность и контакты с аудиторией.

Рынок доставки еды и ресторанов быстрого питания в России — один из наиболее конкурентных цифровых рынков. Успех требует быстрого запуска промо-механик, персонализации предложений и бесперебойной работы в пиковые часы.

Со временем приложение перестало отвечать этим требованиям. Монолитный бэкенд превратился в узкое горлышко для бизнеса. И вот тогда Бургер Кинг обратился к ZeBrains за полным переписыванием бэкенда. Казалось, проще продолжить точечные доработки — система работала, обслуживала миллионы пользователей, зачем всё с нуля? 

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

В таких условиях стартовал масштабный проект по полному переосмыслению продукта — кодовое название «Феникс». Команда ZeBrains отвечала за сердце системы:  проектирование и реализацию бэкенд‑архитектуры, декомпозицию монолита на микросервисы, API‑платформу для мобильного приложения, а также за интеграцию заказов, каталога, цен, платежей, лояльности, уведомлений и аналитики.  Наша цель — стабильность под нагрузкой в 4 раза выше, быстрые релизы и адаптация под другие рынки, без простоя старого приложения.

Ключевые вызовы:

1. Тестирование изменений под экстремальными нагрузками.
2. Ускорение тестов и минимизация ошибок на проде.
3. Отказ от legacy с унификацией стека.

Решение

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

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

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

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

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

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

Этапы работ

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

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

1. заказы и корзина;
2. каталог и рестораны;
3. цены, конфигурации;
4. пользователи и аутентификация;
5. платежи и чеки;
6. лояльность и CRM/CDP;
7. уведомления, чат, отзывы;
8. аналитика и экспорт данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты

1. +1,8 п.п. к конверсии от открытия мобильного приложения до оформления заказа — пользователи быстрее доходят до покупки
2. Удовлетворённость пользователей превысила 95% — целевой показатель достигнут и устойчиво держится
3. +7% к выручке мобильного приложения за счет роста количества заказов
4. Скорость вывода новых функций выросла в 4,5 раза — запуск фич сократился с месяцев до недель 
5. Инциденты, связанные с производительностью, после релиза стремятся к нулю - стабильность Android/iOS держится выше 99,7%, SLA по доступности приложения — выше 99,95%
6. Готовность к нагрузке, в 4 раза превышающей текущую (сейчас DAU более 1 млн) — система уверенно выдерживает пиковые периоды без деградации пользовательского опыта
7. Доля отмен заказов — менее 1%
8. MAU превысил 6 млн пользователей
9. Средний чек: +6,8 руб.

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