Спроектируй масштабируемую платформу ride-sharing в реальном времени, которая обрабатывает непрерывное отслеживание местоположения водителей, эффективное сопоставление водителей и пассажиров на основе близости, динамическое ценообразование, управление состоянием поездки, обработку платежей и функции безопасности. Как бы ты спроектировал архитектуру системы для поддержки частых обновлений местоположения (каждые 3-5 секунд), низколатентных геопространственных запросов для сопоставления, расчётов ETA в реальном времени с учётом данных о трафике и надёжной обработки транзакций?

Обзор архитектуры

Система построена на event-driven микросервисах, где каждый домен (локация, matching, pricing, trips, payments) работает независимо и общается через message broker, например Apache Kafka.

Отслеживание локации в реальном времени

Водители отправляют обновления локации каждые 3–5 секунд через WebSocket-соединения к Location Service.

• Позиции хранятся в Redis с использованием геопространственного индексирования (GEOADD, GEORADIUS)
• Redis обеспечивает запросы по близости с задержкой меньше миллисекунды в масштабе
• Сырые события локации также публикуются в Kafka для downstream-потребителей

Matching водителей и пассажиров

Matching Service подписывается на запросы пассажиров и обращается к Redis для поиска ближайших свободных водителей.

• Пространственные запросы используют GEORADIUS для поиска кандидатов в пределах настраиваемого радиуса
• Кандидаты ранжируются по ETA, а не только по расстоянию
• ETA рассчитывается с помощью графового движка маршрутизации (например, OSRM или Google Maps API) с обогащением данными о трафике в реальном времени

Динамический механизм расчёта цен

Pricing Service считает тариф на основе:

• Соотношения предложения и спроса в заданной области
• Времени суток и исторических паттернов спроса
• Предполагаемого расстояния и длительности поездки

Цены пересчитываются в момент запроса и фиксируются один раз, когда поездка подтверждена.

Управление состоянием поездки

Каждая поездка следует строгой state machine:

Переходы между состояниями сохраняются в PostgreSQL и публикуются как Kafka-события, чтобы синхронизировать все сервисы.

Обработка платежей

• Платежи обрабатываются через выделенный Payment Service, интегрированный со Stripe или Braintree
• Idempotency keys предотвращают дублирование платежей при повторных попытках
• Post-trip событие триггерит авторизацию платежа и генерацию квитанции

Функции безопасности

• Трансляция поездки в реальном времени позволяет пассажирам делиться своей текущей локацией с доверенными контактами
• Anomaly detection помечает неожиданные отклонения от маршрута
• SOS-эндпоинт немедленно оповещает экстренные службы с метаданными поездки