Как разработать агрегатор как DoorDash, Glovo и Foodora: архитектура

Приложение уровня DoorDash, Glovo или Foodora — это не одно мобильное приложение, а связка минимум четырёх продуктов (клиент, курьер, продавец, админка) на общем backend с matching-движком, real-time геолокацией и split-платежами между заказчиком, продавцом и курьером. Главная архитектурная задача — выдержать пиковую нагрузку в обед и вечером без потери заказов и без падения геолокации.

из чего состоит архитектура агрегатора вроде DoorDash и Glovo

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

DoorDash, Glovo и Foodora различаются деталями — у кого-то курьеры штатные, у кого-то фриланс, у кого-то доставка почасовыми слотами, — но архитектурный скелет одинаковый: каталог, заказ, matching, трекинг, выплата. Ошибка в любом из пяти звеньев ломает всю цепочку, и чаще всего ломается она не в разработке, а через полгода после запуска, когда заказов становится в разы больше, чем на тестах.

четыре приложения на одном ядре

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

почему архитектура агрегатора не выдерживает нагрузку в пиковые часы

Пятница, 19:04, доставка еды в Москве. У сети из 40 ресторанов-партнёров одновременно открыто 3200 активных заказов, курьеры массово нажимают «заказ забрал» — и в этот момент клиентское приложение перестаёт обновлять статус доставки. Карта с курьером зависает на одной точке, служба поддержки получает шквал сообщений «где мой заказ», хотя курьер физически едет и всё в порядке.

Причина почти всегда одна: на этапе разработки MVP матчинг заказов и геолокация курьеров спроектированы как синхронные запросы к одной базе. При 50 заказах в час это незаметно. Но при 3000 одновременных заказов база не успевает обрабатывать поток апдейтов координат каждые 3-5 секунд от сотен курьеров сразу — очередь растёт, а не разгружается, поэтому приложение показывает клиенту не текущую позицию, а позицию пятиминутной давности.

Ставка здесь конкретная. Каждая минута простоя live-tracking в пиковый час — это отток клиентов в приложение конкурента, рост нагрузки на поддержку и штрафы от ресторанов-партнёров за сорванный SLA по времени доставки. Для агрегатора с оборотом в несколько сотен заказов в день полчаса сбоя в пятницу вечером — это заметная доля недельной выручки и десятки испорченных отзывов в сторе.

как исправить архитектуру, чтобы выдерживать тысячи заказов одновременно

очередь заказов вместо прямых запросов к базе

Первое, что переделывают в архитектуре после первого пикового сбоя, — matching-движок. Вместо того чтобы каждый апдейт геопозиции курьера писать напрямую в основную базу, поток координат уходит в очередь сообщений (Kafka, RabbitMQ или аналог), а база получает уже агрегированные апдейты раз в 2-3 секунды. Matching-движок читает координаты из отдельного in-memory слоя, а не из транзакционной базы, — это снимает конкуренцию за одни и те же таблицы между заказом, оплатой и трекингом.

геолокация и push-уведомления в реальном времени

Второй слой — вынести live-tracking на WebSocket или отдельный сервис реального времени, а не опрашивать сервер каждые несколько секунд с клиента. Это снижает нагрузку на backend в разы и убирает задержку между «курьер сдвинулся» и «клиент увидел это на карте».

Для B2B-сценариев — например, когда агрегатор работает не только с розничными клиентами, но и обслуживает закупки для сетей магазинов или кафе, — тот же принцип применим к синхронизации остатков и заказов с учётной системой партнёра. Здесь разумно проектировать интеграцию сразу через интеграцию приложения с 1С, а не тянуть данные о наличии товара вручную — иначе именно рассинхрон остатков становится причиной жалоб «заказал, а товара не было».

split-платежи и идемпотентные операции

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

что делать, если сбои матчинга и оплаты повторяются после первого фикса

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

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

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

как предотвратить простои и потерю заказов при масштабировании

Предотвратить сбой дешевле, чем чинить его на боевом трафике.

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

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

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

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

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

Полноценная разработка приложения такого класса — четыре интерфейса, matching-движок, split-платежи, геолокация в реальном времени — начинается от 500 000 рублей и зависит от числа категорий, регионов запуска и глубины интеграции с учётными системами партнёров. Первый релиз обычно закрывает одну категорию, например доставку еды, и один город — это позволяет проверить архитектуру на реальной нагрузке до того, как добавлять вторую категорию и мультирегиональность.

Мы проектируем архитектуру агрегатора с расчётом на рост нагрузки с первого дня: очередь заказов, отдельный сервис геолокации и идемпотентные операции закладываются в MVP, а не дописываются после первого сбоя. Если у бизнеса уже есть учётная система для складов или ресторанов-партнёров, синхронизацию проектируем через 1С:Мобильную платформу там, где это ускоряет запуск, либо через отдельный интеграционный слой — зависит от того, что уже стоит у партнёра.

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

❓ Частые вопросы

Чем архитектура мультикатегорийного агрегатора отличается от обычного интернет-магазина?

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

Можно ли начать с одной категории и одного города, а потом расширяться?

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

Сколько стоит разработать приложение уровня Glovo или DoorDash?

Разработка агрегатора с четырьмя интерфейсами, matching-движком и split-платежами начинается от 500 000 рублей, итоговая сумма зависит от числа категорий, регионов и глубины интеграции с учётными системами партнёров. Точную смету считаем после уточнения объёма функций первого релиза.

Как интегрировать агрегатор с 1С, если у ресторанов или магазинов-партнёров учёт ведётся там?

Синхронизация остатков и заказов настраивается через интеграцию мобильного приложения с 1С — это исключает ситуацию, когда клиент заказал товар, которого уже нет на складе продавца. Решение проектируется индивидуально под конфигурацию 1С у каждого партнёра.

Что произойдёт, если не заложить архитектуру под рост нагрузки с самого начала?

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