Как работает диспетчеризация курьеров в доставке еды

Коротко о том, как это устроено

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

1. собирает пул заказов, которым скоро нужен курьер;
2. собирает пул курьеров: свободных и тех, кто скоро освободится;
3. оценивает возможные пары и связки «курьер — заказы» по функции стоимости;
4. назначает лучшие варианты и отправляет задания в приложение курьера.

Человек-диспетчер остаётся для исключений: отказы, ДТП, проблемные адреса.

Когда назначать курьера

Ключевая идея — курьер должен прийти в ресторан ровно к готовности заказа. Пришёл раньше — простаивает и не возит другие заказы. Пришёл позже — еда остывает.

Поэтому система считает:

• время приготовления — по истории ресторана, блюдам в заказе и текущей загрузке кухни;
• время подъезда курьера к ресторану;
• момент назначения = готовность минус время подъезда минус небольшой запас.

Ресторан помогает точности, если отмечает статусы в планшете или KDS: «принят», «готовится», «готов». Без этих сигналов система опирается только на прогноз.

Батчинг: объединение заказов

Батчинг — когда один курьер везёт несколько заказов за одну поездку. Это экономит курьеров в пиковые часы, но рискует задержать первый заказ.

Условия, при которых объединение обычно оправдано:

• заказы из одного ресторана или соседних;
• адреса доставки по пути друг к другу;
• времена готовности близки;
• добавленная задержка для каждого заказа не выходит за порог, заданный бизнесом.

Порядок точек внутри батча — упрощённая задача маршрутизации (вариант TSP с окнами времени). Для двух-трёх заказов можно перебрать все варианты, для больших объёмов используют эвристики.

Логика назначения

Каждый вариант «курьер + набор заказов» получает стоимость, например:

cost = w1 * время_до_клиента
     + w2 * ожидание_курьера_в_ресторане
     + w3 * опоздание_относительно_обещанного_ETA
     + w4 * пробег_курьера

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

• жадный: по очереди назначать лучший доступный вариант — просто и быстро, но не оптимально;
• оптимизационный: решать назначение на весь пул сразу (например, венгерский алгоритм или солверы) — лучше результат, сложнее реализация;
• отложенное решение: заказ ждёт несколько секунд, вдруг появится более удачная связка.

Дополнительно учитывают тип транспорта, вместимость термосумки, зону курьера и время до конца смены.

Как считается ETA

ETA складывается из этапов:

Начинают обычно с простых средних по этапам, затем переходят к ML-модели, которая учится на фактических временах. Важно пересчитывать ETA при каждом изменении статуса и показывать клиенту честный интервал, а не оптимистичную точку.

Архитектура трекинга

Типичная схема:

• приложение курьера отправляет GPS-координаты раз в несколько секунд, с батчингом точек при плохой связи;
• шлюз приёма складывает их в очередь или стрим (Kafka, Redis Streams и подобные);
• сервис местоположений хранит последнюю позицию курьера в быстром хранилище с геоиндексом для поиска ближайших;
• диспетчер читает позиции и статусы заказов;
• клиент получает обновления через WebSocket или периодический опрос.

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

Частые ошибки

• Назначать курьера сразу при оформлении заказа — он долго ждёт на кухне.
• Агрессивный батчинг, из-за которого первый клиент получает холодную еду.
• ETA без учёта «последних метров» и загрузки конкретного ресторана.
• Отсутствие ручного режима для диспетчера, когда алгоритм ошибается.