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

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

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

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

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

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

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

• Тестирование изменений под экстремальными нагрузками.

• Ускорение тестов и минимизация ошибок на проде.

• Отказ от legacy с унификацией стека.

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

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

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

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

• спроектирована доменно-ориентированная сервисная архитектура: центральный монолит распилили на независимые сервисы (заказы, каталог, цены, платежи, лояльность, аналитика и другие);

• каждый сервис получил чёткую зону ответственности и собственную базу данных;

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

• реализовано покрытие unit-тестами новых сервисов и внедрены автотесты любых изменений;

• добавлено непрерывное нагрузочное тестирование для обеспечения стабильности под высокой нагрузкой.

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

• заказы и корзина;

• каталог и рестораны;

• цены, конфигурации;

• пользователи и аутентификация;

• платежи и чеки;

• лояльность и CRM/CDP;

• уведомления, чат, отзывы;

• аналитика и экспорт данных.

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

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

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

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

• каталог продуктов и управление ресторанами;

• система цен и промо-механик;

• платёжные интеграции.

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

• перевели требования в работающие сценарии;

• проработали граничные случаи и исключения;

• обеспечили согласованность данных между сервисами.

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

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

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

• API Gateway;

• единая точка входа для мобильного приложения;

• маршрутизация запросов;

• прозрачность для пользователя;

• откат на старую систему в случае проблем;

• упрощение разработки backend-сервисов — изменения внутри сервисов не требуют доработок на фронтенде, если не меняется контракт.

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

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

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

• поиск узких мест производительности;

• оптимизация критических путей.

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

• дашборды производительности;

• алерты на аномалии;

• сбор технических и продуктовых метрик.

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

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

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

• сбор первичной обратной связи.

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

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

• мониторинг стабильности и производительности;

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

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

• постепенная раскатка 1% → 5% → 100% пользователей с отслеживанием конверсионных и технических метрик;

• сбор отзывов из сторов и их обработка;

• при обнаружении проблем — остановка раскатки, исправление, продолжение;

• валидация всех критических сценариев.

• +1,8 п.п. к конверсии от открытия мобильного приложения до оформления заказа — пользователи быстрее доходят до покупки

• Удовлетворённость пользователей превысила 95% — целевой показатель достигнут и устойчиво держится

• +7% к выручке мобильного приложения за счет роста количества заказов

• Скорость вывода новых функций выросла в 4,5 раза — запуск фич сократился с месяцев до недель

• Инциденты, связанные с производительностью, после релиза стремятся к нулю - стабильность Android/iOS держится выше 99,7%, SLA по доступности приложения — выше 99,95%

• Готовность к нагрузке, в 4 раза превышающей текущую (сейчас DAU более 1 млн) — система уверенно выдерживает пиковые периоды без деградации пользовательского опыта

• Доля отмен заказов — менее 1%

• MAU превысил 6 млн пользователей

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

• Но главное — изменение возможностей продукта. Теперь появление новой продуктовой идеи не упирается в архитектурные ограничения. Бизнес получил платформу, которая растёт вместе с ним.