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

1. Вводная задача от заказчика, проблематика, цели

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

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

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

В таких условиях стартовал масштабный проект по полному переосмыслению продукта — кодовое название «Феникс». Он включал глубокие исследования пользовательского опыта, полный редизайн интерфейсов, расширение функциональности, переработку программы лояльности и разработку нового фронтенда для iOS и Android. Над всеми этими компонентами работала большая кросс-функциональная команда

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

Ключевые проблемы на момент старта:

• Центральный монолит с критической бизнес-логикой — единая точка отказа всей системы, невозможность независимого масштабирования отдельных функций

• Достигнут потолок производительности — система переставала справляться с нагрузкой в пиковые периоды (обеды, акции, выходные)

• Увеличение Time-to-Market до 1 квартала — цикл поставки новой ценности до пользователя вырос с недель до месяцев

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

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

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

2. Описание реализации кейса и творческого пути по поиску оптимального решения

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

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

Этапы реализации

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

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

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

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

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

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

• Платежи и чеки

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

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

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

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

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

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

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

Центральный элемент новой архитектуры — API Gateway (Composition Layer). Единая точка входа для мобильного приложения, которая:

• Стандартизирует взаимодействие фронтенда и бэкенда — изменения внутри сервисов не требуют доработок на клиенте

• Обеспечивает безопасную параллельную работу — старый и новый бэкенд существовали одновременно, маршрутизация прозрачна для пользователя

• Даёт мгновенный откат — если что-то идёт не так, трафик за секунды возвращается на старую систему без последствий для пользователей

Это решение позволило мигрировать миллионную аудиторию поэтапно и контролируемо — без единой минуты запланированного простоя.

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

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

Этап 5. Закрытое тестирование и постепенная раскатка

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

3. Результаты сотрудничества

Для пользователей результат выглядит просто: «Новое приложение — быстрее, стабильнее и удобнее».

Для бизнеса — это платформа для роста. Теперь появление новой продуктовой идеи не упирается в архитектурные ограничения. Бургер Кинг получил возможность реализовывать сложные сценарии (персонализированные предложения, динамические промо, кастомизацию заказов), которые раньше были технически невозможны.

Главное изменение — возможности продукта. Архитектура больше не ограничивает бизнес — она растёт вместе с ним.

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

4. Заключение

Мы провели полную перезагрузку бэкенда мобильного приложения одного из крупнейших ресторанов быстрого питания в России. Переписали инфраструктуру, обслуживающую миллионы пользователей, при этом без единой минуты простоя

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

От первой встречи до публичного релиза всего приложения — 1 год 4 месяца и 11 дней. Для проекта такого масштаба и сложности это достойный результат.

Новый бэкенд стал платформой для всей экосистемы Бургер Кинг. Уже сейчас в планах унификация бэкенда для киосков, драйвов и веб-сайта. Архитектура спроектирована так, чтобы обеспечить стабильность и скорость работы приложения даже под экстремальной нагрузкой.

Над проектом работала большая кросс-функциональная команда Бургер Кинг, ZeBrains и еще нескольких партнеров: продуктовые менеджеры, дизайнеры, frontend-, mobile- и backend-разработчики, аналитики, QA-инженеры, Devops-инженеры и другие.

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