Как создать приложение такси: ключевые компоненты и архитектура

Из чего состоит сервис такси

Приложение такси — это не одно приложение, а система из нескольких частей:

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

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

Приложение пассажира

Минимальный набор функций:

• выбор точки подачи и назначения с подсказками адресов и уточнением пина на карте;
• выбор тарифа и предварительная цена до заказа;
• поиск машины, карточка водителя и автомобиля, машина на карте в реальном времени;
• оплата наличными, картой или из баланса;
• чат или звонок через маскированный номер, кнопка «поделиться поездкой»;
• история поездок, чеки, оценка.

Приложение водителя

• статус «на линии / не на линии» и фоновая передача геопозиции — с учётом ограничений iOS и Android на фоновую работу;
• входящий заказ с таймером на принятие, расстояние до клиента и ориентировочная стоимость;
• навигация через встроенную карту или внешние навигаторы;
• статусы поездки: еду к клиенту, на месте, в пути, завершено;
• баланс, комиссии, выплаты, документы.

Панель диспетчера

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

Матчинг: как назначается заказ

1. Найти свободных водителей рядом с точкой подачи — через геоиндекс (гексагональные сетки вроде H3, geohash или PostGIS).
2. Отсеять неподходящих: тариф, класс авто, детское кресло, блокировки.
3. Отсортировать по времени подачи по дорогам, а не по прямой — река или односторонняя улица всё меняют.
4. Предложить заказ одному или нескольким водителям с таймером; при отказе — следующему.

Альтернатива последовательной рассылке — пакетное назначение: система копит заказы пару секунд и распределяет их так, чтобы минимизировать суммарное ожидание по всем пассажирам.

Тарифы и surge

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

Surge (повышающий коэффициент) включается, когда в зоне спрос выше предложения. Он рассчитывается по зонам и коротким окнам времени. Важно:

• показывать коэффициент пассажиру до заказа;
• сглаживать скачки, чтобы цена не прыгала каждую минуту;
• проверить, как повышающие коэффициенты регулируются местными правилами.

Карты и геоданные

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

Оплата

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

Real-time на масштабе

Архитектурные решения, которые закладывают с первого дня:

• Постоянное соединение (WebSocket или MQTT) для координат и статусов, push-уведомления как резерв.
• Координаты водителей — в быстром хранилище в памяти (например, Redis с гео-командами), а не в основной БД на каждую точку.
• Треки поездок пишутся через очередь сообщений и сохраняются пакетами.
• Поездка — конечный автомат со строгими переходами; одновременное принятие заказа двумя водителями исключается атомарной операцией.
• Сервисы разделены по нагрузке: геолокация и матчинг масштабируются отдельно от биллинга и админки.

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

• Матчинг по прямой без учёта дорог.
• Отсутствие офлайн-логики: водитель потерял связь посреди поездки, и заказ «завис».
• Нет панели диспетчера на старте — все сбои превращаются в ручную работу в базе.