Почему приложение такси ломается на пике заказов
Пик заказов вскрывает то, что не видно на тестовом стенде: приложение такси перестаёт быть набором экранов и превращается в систему реального времени, где рассинхрон на секунду стоит потерянного водителя. Первым сдаётся матчинг — при шторме заказов два диспетчерских узла одновременно назначают одного водителя на две поездки, и оба пассажира видят «машина едет», пока водитель видит один адрес. Дальше каскад: заказ уходит в очередь, но событие о назначении теряется, и поездка зависает в статусе «поиск» — пассажир отменяет, водитель простаивает, а сервис платит за оба простоя репутацией.
Точность геолокации в приложении такси ломается иначе. На плотной застройке телефон отдаёт координаты с дрейфом, а при слабом сигнале — с задержкой в десятки секунд. Если точка водителя обновляется реже, чем меняется его положение, карта рисует машину там, где её уже нет, а расчёт времени подачи врёт. Пассажир выходит на улицу и не находит автомобиль — формально система сработала, фактически поездка сорвана. Проблема не в самой карте, а в том, как приложение фильтрует и сглаживает поток координат перед отправкой на сервер.
Отдельный класс — отвал платежей. Привязанная карта списывается в момент завершения поездки, и если эквайринг отвечает медленно или возвращает неоднозначный статус, деньги не списываются, а поездка закрывается. Повторный запрос без идемпотентности приводит к двойному списанию — и это уже не технический сбой, а возвраты, обращения и потеря доверия. Сбои матчинга водителей, зависшие заказы такси и платежи — это одна связанная цепочка, где слабое звено определяет надёжность всего сервиса.
Цена каждого узкого места считается не в строчках кода, а в сорванных поездках: доля заказов, дошедших до завершения, время от заявки до назначения водителя, доля отмен по вине системы. Разбираем, как это закрывается на уровне архитектуры — от очередей и блокировок до обработки координат и идемпотентных платежей.
Архитектура сервиса такси: матчинг, гео, платежи
Разработка приложения для такси держится на трёх подсистемах, каждая из которых измеряется своими метриками. Матчинг определяет, за сколько секунд заказ находит водителя и какую долю поездок удаётся закрыть без отмен. Геолокация в приложении такси задаёт точность позиции и плавность трека на карте. Интеграция платежей в такси — долю успешных списаний и скорость возвратов при отмене. Ниже — как эти части устроены и что даёт каждая.
Матчинг: жадный против батчевого
Жадный алгоритм матчинга водителей отдаёт заказ ближайшему свободному водителю сразу — просто, но на пиковых зонах даёт перекос: часть машин едет через весь район, время подачи растёт. Батчевый матчинг собирает заявки окнами по несколько секунд и решает задачу распределения целиком — время подачи падает, доля успешных заказов растёт, но появляется задержка на само окно. На практике ставят гибрид: жадный в центре, батчевый в плотных зонах.
Геолокация: частота и точность
Позиция водителя приходит потоком; если писать каждую точку в базу, она захлёбывается на сотнях машин. Точки буферизуются в памяти и сбрасываются пакетами, а карта получает сглаженный трек — без рывков и «телепортов» между замерами. Это снижает нагрузку на хранилище и убирает ложные срабатывания геозон.
Платежи: идемпотентность и возвраты
Списание привязано к поездке уникальным ключом, поэтому повторный запрос не создаёт второе списание. Отмена инициирует возврат тем же ключом — деньги не «зависают», а спорные операции разбираются по логу.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Жадный матчинг | Низкая плотность заказов, малый город | Перекос на пиках, растёт время подачи |
| Батчевый матчинг | Плотные зоны, высокая конкуренция за заказ | Задержка на окно, сложнее отладка |
| Гибрид | Города со смешанной нагрузкой | Нужна настройка порогов по зонам |
| Внешний платёжный шлюз | Быстрый старт, готовые методы оплаты | Зависимость от чужого SLA |
| Собственный платёжный слой | Полный контроль над возвратами и логами | Больше работы на старте |
PostGIS для геозапросов и построения зон — проверенный слой, который держит пространственные выборки под нагрузкой.
Каждая подсистема закрывает свой класс отказов: матчинг — долгие подачи и отмены, гео — неточные треки и ложные геозоны, платежи — двойные списания и зависшие возвраты.
Как мы ведём проект: от аудита до передачи
Разработка приложения для такси редко стартует с чистого листа: чаще есть диспетчерская, водительское приложение, база заказов и набор интеграций, которые уже работают — и ломаются под нагрузкой в час пик. Поэтому проект ведём как инженерную последовательность, где каждый этап даёт проверяемый артефакт, а не статус в отчёте. Ниже — как это устроено.
- Аудит текущего состояния. Разбираем существующие сервисы, схемы данных, логи матчинга и жалобы поддержки. На выходе — карта узких мест: где теряются заказы, на каком шаге водитель и пассажир видят рассинхрон, какие интеграции держат систему.
- Схема сервисов и границ ответственности. Фиксируем, что остаётся, что переписываем, что выносим в отдельный контур. Определяем контракты между матчингом, геолокацией, платежами и уведомлениями — чтобы изменения в одном не роняли остальные.
- Матчинг и геолокация. Настраиваем радиусы поиска, приоритеты водителей, обработку «холодных» зон и очередей заказов. Отдельно — поведение при потере сигнала: заказ не должен зависать в статусе «ищем машину».
- Платежи и статусы поездки. Проводим сквозной путь оплаты: холдирование, списание, возврат, отмена на разных этапах. Сверяем, что состояние заказа в приложении, на сервере и в платёжном контуре совпадает.
- Тестирование под нагрузкой. Прогоняем сценарии пиковых часов: всплеск заказов, массовый выход водителей на линию, обрыв связи у части клиентов. Смотрим время отклика матчинга и долю заказов, доведённых до назначения водителя.
- Передача проекта заказчику. Отдаём репозитории, схемы сервисов, конфигурации окружений, инструкции по развёртыванию и регламент релизов. Команда заказчика может собрать, выкатить и откатить версию без нас.
Каждый этап заканчивается демонстрацией на реальных данных, а не презентацией. Если на аудите видно, что дешевле починить существующий контур, чем строить новый, — говорим об этом прямо. Опишите задачу: вернёмся с оценкой и планом по этапам.
Чем отличается собственный матчинг от готового?
Готовое решение для такси — это библиотека матчинга внутри платформы: вы отдаёте ей координаты водителей и заказов, а на выходе получаете пару «водитель–заказ». Логика закрыта: ближайший свободный, очередь, простые приоритеты. Для города с ровным спросом и парком в несколько десятков машин этого достаточно — запуск быстрее, поддерживать нечего, поведение предсказуемо.
Собственный матчинг заказов начинается там, где готовая логика перестаёт учитывать вашу экономику. Распределение заказов такси — это не «кто ближе», а задача с ограничениями: удержать водителя в зоне повышенного спроса, не дать ему простаивать после дальней подачи, сбалансировать загрузку между районами, учесть рейтинг, класс авто и историю отмен. Готовое решение такие веса либо не поддерживает, либо прячет за фиксированными настройками.
Разница проявляется в метриках, а не в описании. Свой алгоритм позволяет менять приоритеты без релиза приложения — правило на стороне сервиса, водитель получает обновлённую логику сразу. Это даёт управляемый процент подач в пределах целевого времени, снижение холостого пробега и предсказуемую загрузку в часы пик. Обратная сторона — матчинг становится вашей ответственностью: тесты, нагрузка, откат версий, мониторинг аномалий.
Сравнение подходов матчинга сводится к трём вопросам. Насколько ваша экономика отличается от типовой — если сильно, готовая логика будет тянуть вниз. Есть ли у вас данные и люди, чтобы крутить веса — свой алгоритм без аналитика бесполезен. И как быстро нужен запуск — готовое решение выводит продукт на рынок раньше, а свой матчинг окупается на объёме, когда каждая доля процента подач конвертируется в выручку парка.
Практичный путь — гибрид: старт на готовой логике, сбор телеметрии по подачам и отказам, затем вынос матчинга в отдельный сервис, когда накопится статистика для весов. Так вы не платите за сложность раньше времени и не упираетесь в потолок готового решения, когда парк вырастет.
Кейс: как выросла доля успешных заказов
Сервис работал на подрядной сборке: заявка уходила в ручной диспетчер, водитель получал адрес текстом и звонил уточнять подъезд. На пике вечерних часов это давало до 28% отмен — пассажир уходил к конкуренту, пока машина кружила по двору. Метрики сервиса такси мы снимали с двух сторон: события в приложении пассажира и в приложении водителя, плюс журнал диспетчерской — расхождение между ними и показало, где теряются заказы.
Что изменили в матчинге и геолокации
Переписали ядро распределения: заявка больше не ждёт свободного диспетчера, а уходит напрямую ближайшим водителям с учётом их текущего курса и загруженности улиц. Точку подачи определяем по геокоду здания, а не по центроиду района — водитель приезжает к конкретному подъезду, звонок «где вы стоите» исчезает из сценария. Это убрало основную причину отмен на этапе подачи.
Что изменили в оплате
Платёжный сценарий перевели на токенизацию карты при первом заказе: списание идёт без повторного ввода данных и без редиректа на стороннюю страницу. Доля платежей, падающих на подтверждении, сократилась с 9% до 1,5% — водитель видит статус оплаты до начала поездки и не отменяет заказ из-за риска не получить деньги.
| Метрика | До | После |
|---|---|---|
| Среднее время подачи | 11 мин | 6 мин |
| Доля отмен заказов | 28% | 9% |
| Точность геопозиции подачи | ±180 м | ±25 м |
| Успешные оплаты с первой попытки | 91% | 98,5% |
Данные собирали две недели до релиза и три недели после, на сопоставимом объёме заказов и в одинаковые часы — сравнение корректное, а не «до праздников и после». Отдельно считали долю успешных заказов такси от созданных: рост с 64% до 88%, то есть каждый четвёртый потерянный заказ вернулся в выручку без привлечения новых водителей. Матчинг построен на открытом стеке геопространственных запросов — PostGIS держит индекс по координатам и отдаёт ближайших водителей за доли секунды даже на плотном потоке.
Что если водители работают на старых телефонах? Ядро матчинга живёт на сервере, приложение водителя только отправляет координаты и получает заявку — требования к устройству не выросли, обновление проходит без замены парка.
Как откатывались, если метрики падали? Релиз шёл за переключателем: старая логика распределения оставалась рабочей, возврат занимал минуты и не требовал выкатывать новую сборку в магазины.
На руки заказчик получает схему потока заявки, конфигурацию геоиндексов, политику ретраев платежей, дашборд по метрикам сервиса и инструкцию для поддержки. Опишите свою задачу — вернёмся с оценкой и планом.
Сомнения перед стартом: доступы, миграция, откат
Перед стартом разработки приложения для такси заказчик обычно держит в голове три вопроса: что придётся отдать подрядчику, как пройдёт миграция сервиса такси с текущего решения и что будет, если новый релиз сломает поездки в час пик. Отвечаем по существу: доступы к инфраструктуре выдаются по принципу минимально необходимых — отдельные учётные записи с ограниченной ролью, ключи к платёжному контуру и картам остаются у вас, а наши инженеры работают через ваш контроль доступа с журналом действий.
Что если понадобится откат изменений? Каждый релиз выкатывается поэтапно: сначала на долю водителей и пассажиров, затем на весь поток. Пока новая версия не подтвердила стабильность, предыдущая сборка остаётся готовой к возврату — переключение занимает минуты, а не часы простоя. Схема данных при миграции расширяется совместимо: старые и новые поля живут параллельно, поэтому откат не требует обратного преобразования базы.
Что если у вас уже есть работающий сервис? Переносим по частям — сначала матчинг и геолокацию, затем платежи и историю поездок, сверяя метрики на каждом шаге. Пока новый контур не показывает сопоставимые результаты, старый продолжает обслуживать заказы.
Кому принадлежат исходники и доступы после сдачи?
Всё остаётся у вас: репозитории, инфраструктурные учётные записи, ключи, домены. Мы передаём их по акту и отзываем свои доступы — дальнейшая поддержка идёт уже по отдельному соглашению.
На руки заказчик получает:
- конфигурации окружений (разработка, тест, продуктив) с описанием переменных;
- схемы архитектуры и потоков данных: геолокация, матчинг, платежи, уведомления;
- политики доступа и ролевую модель для команды и подрядчиков;
- регламент релизов и процедуру отката изменений с критериями;
- документацию по проекту: описание модулей, интеграций и точек отказа;
- инструкции по мониторингу ключевых метрик — время подачи, доля отмен, ошибки платежей.
Опишите задачу и текущий контур — вернёмся с оценкой, планом миграции и составом передаваемой документации.
