Как Создать Приложение для Доставки Еды (GrubHub)

Архитектура: четыре роли, одна система

Любое приложение по типу GrubHub — это маркетплейс под ключ с тремя типами пользователей (клиент, курьер, ресторан) и одним оператором системы (админ). Ошибка, которую мы регулярно видим на этапе ТЗ, — команда проектирует эти роли как отдельные приложения с дублирующей логикой вместо единой продуктовой архитектуры с разными правами доступа.

Мы решаем это так же, как на проектах с мультиролевой архитектурой в финтехе: один тип роли («партнёр») получает разные права через флаги вместо отдельных кабинетов, а заявки фильтруются по статусу вместо создания параллельных интерфейсов. Это снижает сложность на 100% там, где команда обычно закладывает overengineering ещё до старта разработки.

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

Challenge: очередь заказов под нагрузкой

Challenge: на одном из high-load проектов асинхронная обработка задач шла через web-сервисы, worker-ы и cron jobs, но фреймворк не поддерживал Kafka нативно, а некорректное закрытие сессий worker-процессов приводило к потере сообщений при рестартах — прямой аналог ситуации, когда очередь заказов «теряет» события при пересборке кластера.

Solution: мы развернули трёхуровневую архитектуру (HTTP-сервисы, worker-ы для queue processing, cron jobs как отдельные Kubernetes deployments), интегрировали Kafka через кастомную библиотеку с явной реализацией graceful shutdown, а секреты доступа к брокеру вынесли в HashiCorp Vault с JWT-аутентификацией через единый Helm chart для всех сервисов.

Result: ноль потерянных сообщений при рестартах worker-процессов, унифицированный деплой, который позволяет добавлять новые микросервисы без операционного хаоса.

Сколько стоит разработка и сколько это занимает времени

Прямых аналогов GrubHub в нашем портфеле оценок нет, поэтому даём ориентир на основе проектов сопоставимой сложности — маркетплейсов с мультиролевой архитектурой, геолокацией и real-time коммуникацией.

Отдельные модули считаются точечно и часто выпадают из первичной оценки: real-time чат между клиентом и курьером — от $5,000, интеграция платёжного шлюза — от $3,500, панель администратора с разграничением ролей (контент-менеджер, финансовый отдел, оператор поддержки) — от $1,500, кастомная CMS для управления меню и новостями — $8,000–$16,000. Детальный разбор стоимости разработки приложения для доставки еды помогает свести это в единый бюджет ещё на этапе брифа.

Клиентское приложение: где реально теряются деньги

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

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

Приложение курьера: real-time геолокация и матчинг

Модуль курьера — самая технически нагруженная часть системы, потому что здесь одновременно работают геолокация в реальном времени, push-уведомления о новом заказе и логика назначения (матчинга) курьера на заказ. Механика назначения похожа на диспетчеризацию в приложениях такси: система оценивает расстояние до ресторана, текущую загрузку курьера и ограничение по времени (SLA-таймер на принятие заказа), после чего отправляет push-уведомление.

Challenge: устойчивость под пиковой нагрузкой

Challenge: при нагрузочном тестировании похожей real-time системы обнаружили, что база данных, Redis и приложение работали на одном сервере — под нагрузкой на исторические запросы (аналог: история заказов и маршрутов курьера) происходила взаимная деградация ресурсов, а прод-кластер оставался single-node, то есть один неконтролируемый cron job мог обрушить весь кластер через OOM.

Solution: мы вынесли базу данных на отдельный инстанс, добавили composite-индексы вместо full table scan на тяжёлых запросах и перевели периодические задачи (пересчёт ETA, обновление позиций курьеров) с голого cron на управляемые Kubernetes CronJobs с жёсткими CPU/RAM limits.

Result: система проходит нагрузочное тестирование без деградации 95-го перцентиля latency на критичных эндпоинтах и без cascade failures в часы пиковой нагрузки.

Готовое решение с этой логикой уже внутри — вариант для тех, кто хочет проверить бизнес-модель без разработки с нуля.

Кабинет ресторана-партнёра

Партнёр должен управлять меню, ценами и доступностью блюд без обращения в поддержку. Стандартный набор: изменение карточки заведения, добавление/удаление позиций меню, статистика по заказам, отчёты и сметы. Здесь снова работает принцип единой роли с разными правами: владелец сети ресторанов получает доступ ко всем точкам, менеджер одной точки — только к своей.

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

Админ-панель, роли и безопасность

Разграничение ролей — не декоративная фича, а требование к архитектуре: главный администратор видит всё, контент-менеджер — только контент и меню, финансовый отдел — отчёты и биллинг, оператор поддержки — статусы заказов и чаты. Мы выносим секреты (доступы к платёжным шлюзам, API ресторанов) в HashiCorp Vault с JWT-аутентификацией — тот же подход, который используем в финтех-проектах, где нельзя хранить чувствительные данные в переменных окружения открытым текстом.

Отдельный момент — данные банковских карт, которые приложение запрашивает при регистрации. Правильная архитектура не хранит их напрямую: платёжный шлюз токенизирует карту, а приложение хранит только токен. Это не опция, а требование PCI DSS, и его стоит закладывать в ТЗ до старта разработки, а не после первого инцидента.

Native или кросс-платформенное приложение

Курьеру и клиенту нужны разные приоритеты: курьеру — стабильная фоновая геолокация и push без задержек, клиенту — быстрый и приятный UI. Поэтому мы обычно рекомендуем нативную разработку (Kotlin/Swift) для курьерского приложения и рассматриваем React Native или Flutter для клиентского — там, где фоновая работа с GPS не критична. Разработка мобильных приложений для iOS и Android с нуля на двух нативных стеках дороже, но снимает риски с производительностью геолокации, которые кросс-платформенные решения регулярно упираются в системные ограничения фоновых процессов.

Масштабирование под пиковую нагрузку

Delivery-сервис не имеет равномерной нагрузки — трафик концентрируется в обеденное и вечернее время, а вне пиков инфраструктура простаивает. Асинхронная обработка через Redis и Kafka вместе с Kubernetes resource requests/limits решает именно эту задачу: система масштабирует worker-ы под пик и возвращается к базовому уровню ресурсов вне его, вместо того чтобы держать пиковую мощность круглосуточно. Это тот же принцип, который мы описывали для агрегаторов доставки еды с каталогом ресторанов — модель нагрузки там идентична.

Что дальше

Приложение по типу GrubHub — это система с высокой конкуренцией за ресурсы в пиковые часы, а не витрина с каталогом и корзиной. Архитектурные решения, которые кажутся необязательными на этапе MVP — очередь сообщений, разграничение ролей, вынесение секретов в Vault — становятся дорогими, если добавлять их после запуска под реальной нагрузкой. Мы закладываем это на старте, поэтому оценка стоимости разработки мобильного приложения для бизнеса у нас включает архитектуру, а не только экран за экраном.

FAQ