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

Клиент
Бургер Кинг
Сфера
Рестораны, общественное питание
Дата релиза
март 2026
Задача

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

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

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

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

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

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

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

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

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

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

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

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

  • спроектирована доменно-ориентированная сервисная архитектура: центральный монолит распилили на независимые сервисы (заказы, каталог, цены, платежи, лояльность, аналитика и другие);
  • каждый сервис получил чёткую зону ответственности и собственную базу данных;
  • архитектура изначально допускает рост — новые домены добавляются без переписывания ядра. Итоговый бэкенд состоит из порядка 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% → 100% пользователей с отслеживанием конверсионных и технических метрик;
  • сбор отзывов из сторов и их обработка;
  • при обнаружении проблем — остановка раскатки, исправление, продолжение;
  • валидация всех критических сценариев.
Технологии
Golang
PHP Symfony
Redis
gRPC
Kafka
Kubernetes
Результат
  • +1,8 п.п. к конверсии от открытия мобильного приложения до оформления заказа — пользователи быстрее доходят до покупки
  • Удовлетворённость пользователей превысила 95% — целевой показатель достигнут и устойчиво держится
  • +7% к выручке мобильного приложения за счет роста количества заказов
  • Скорость вывода новых функций выросла в 4,5 раза — запуск фич сократился с месяцев до недель
  • Инциденты, связанные с производительностью, после релиза стремятся к нулю - стабильность Android/iOS держится выше 99,7%, SLA по доступности приложения — выше 99,95%
  • Готовность к нагрузке, в 4 раза превышающей текущую (сейчас DAU более 1 млн) — система уверенно выдерживает пиковые периоды без деградации пользовательского опыта
  • Доля отмен заказов — менее 1%
  • MAU превысил 6 млн пользователей

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

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

Ильяс Домнин
CPO Бургер Кинг

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

Благодаря вашей работе нам удалось своевременно продвинуться по ключевым этапам проекта. Рассчитываем на продолжение продуктивного сотрудничества в будущем.

Спасибо за профессионализм и ответственное отношение к делу!

Команда
проекта
Backend разработчик
Менеджер проекта
QA
Руководитель разработки

Обсудить
проект