как разработать приложение как delivery club: архитектура и опыт запуска

Приложение уровня delivery club — это не дизайн экрана заказа, а архитектура: отдельные сервисы для каталога, заказов, курьеров и платежей, очередь сообщений между ними и обмен с учётной системой в реальном времени. Скопировать интерфейс легко, а систему, которая выдерживает рост заказов в 10 раз, — нет: её строят с нуля под конкретный бизнес.

как устроена архитектура приложения уровня delivery club

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

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

почему монолит не масштабируется так же линейно

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

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

Сеть из трёх суши-баров в Москве заказала мобильное приложение у подрядчика: три месяца работы, бюджет около 700 тысяч рублей, всё в срок. Полгода приложение спокойно держало 40-60 заказов в день — ровно столько, сколько было при запуске. Потом открыли четвёртую точку и объявили в telegram-канале на 12 тысяч подписчиков акцию «второй ролл в подарок».

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

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

как исправить архитектуру, если приложение уже не тянет нагрузку

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

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

Третий шаг — кэш каталога. Меню ресторана не меняется каждую секунду, поэтому нет смысла бить по основной базе при каждом открытии приложения — кэш снимает 80-90% этой нагрузки без единой строчки бизнес-логики.

Четвёртый шаг — нагрузочное тестирование перед каждой крупной акцией, а не после того, как приложение легло. Сценарий с ожидаемым пиком прогоняют заранее и смотрят, где рвётся первым.

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

что делать, если приложение продолжает падать после первого исправления

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

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

Нагрузочный тест здесь нужен не формальный, а построенный на реальном сценарии: не «100 одинаковых запросов подряд», а всплеск открытий приложения за 10-15 минут, как это происходит при настоящей акции. Отдельно стоит завести мониторинг с алертами — чтобы о деградации узнавал разработчик по сообщению в 21:40, а не менеджер по звонку от разгневанного клиента в 22:00. Если проблема упирается именно в ресурс сервера, а не в код, следующий шаг — вынести базу с заказами на отдельную выделенную мощность, а не продолжать делить её с остальными сервисами компании.

что делать, если интеграция с 1С не поспевает за ростом заказов

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

Но в обеденный час, когда за 15 минут прилетает 50-60 заказов одновременно, 1С не успевает ответить в отведённое время. Приложение показывает клиенту «ошибка оформления заказа», хотя заказ на самом деле уже создался в базе. Поэтому клиент либо пытается оплатить повторно, либо звонит в кофейню и не может дозвониться, потому что линия занята другими такими же звонками.

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

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

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

как предотвратить типичные ошибки при разработке приложения как delivery club

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

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

сколько стоит разработать приложение уровня delivery club

Разработка мобильного приложения в ukved.ru начинается от 500 000 рублей — это стартовая цена для одного приложения с базовой архитектурой. Итоговый бюджет зависит от количества отдельных приложений в системе (клиентское, курьерское, админ-панель для ресторана), глубины интеграции с 1С и того, закладывается ли архитектура сразу под рост или под текущий объём заказов.

Разница в цене между «сделать красивый экран заказа» и «сделать систему, которая не упадёт на акции» — это разница между интерфейсом и инфраструктурой под ним. Актуальные тарифы и что входит в каждый пакет — на странице цены и тарифы.

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

Можно ли скопировать интерфейс delivery club и получить такое же рабочее приложение?

Нет. Экраны заказа и каталога скопировать реально, а вот очередь сообщений, разделение сервисов и обмен с учётной системой под капотом — нет. Именно эта часть держит нагрузку при росте заказов, а не внешний вид карточек товара и кнопок оформления заказа.

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

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

Как понять, что приложению пора менять архитектуру?

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

Можно ли обойтись без отдельного бэкенда и работать прямо на 1С?

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

Нужно ли отдельное приложение для корпоративных клиентов?

Если у бизнеса есть офисная доставка, контракты с лимитами на сотрудника и закрывающими документами — да, эту логику лучше вынести в отдельный B2B-контур с собственным согласованием заявок, а не встраивать в обычный клиентский сценарий оформления заказа.