Uber-подобный сервис ломается не на карте, а в момент, когда нужно за доли секунды сопоставить движущийся спрос и движущееся предложение.
Глава связывает в одну архитектуру поток координат, диспетчеризацию, расчёт ETA, жизненный цикл поездки, динамическую надбавку к цене и расчёты после завершения заказа.
В интервью и инженерных обсуждениях этот кейс полезен тем, что быстро показывает, умеете ли вы проектировать под жёсткий бюджет задержки и при этом не терять корректность состояний поездки.
Поток координат
Координаты водителей приходят непрерывно, поэтому приём потока, TTL и свежесть геоиндекса нужно проектировать как отдельный критичный контур.
Диспетчеризация
Контур назначения водителя должен быстро находить кандидатов и устойчиво переживать тайм-ауты, отказы и повторные попытки.
ETA и маршрут
ETA зависит не только от карты, но и от трафика, пересчёта маршрута и своевременной доставки обновлений в клиентские приложения.
Пиковый спрос
Баланс спроса и предложения меняется по зонам и по минутам, поэтому логику динамической надбавки нельзя считать второстепенной деталью продукта.
Uber/Lyft удобно разбирать как , где жёсткие требования к напрямую влияют на продукт: если водитель находится слишком долго, пользователь просто закрывает приложение. Поэтому здесь важно не только показать карту и машины, но и быстро связать поток координат, подбор водителя, расчёт цены и жизненный цикл поездки в одну устойчивую систему.
Источник
System Design Interview
У Alex Xu есть отдельные приёмы для proximity-сервисов, геоиндексов и потоков координат в мобильных продуктах.
Масштаб продукта
Uber
Uber Engineering Blog
Технические статьи о внутренних сервисах Uber: от геопотоков до расчёта маршрута и цен.
1Функциональные требования
Путь пассажира
- •Указать точку подачи, пункт назначения и тип поездки
- •Увидеть цену и время подачи до подтверждения заказа
- •Получить назначенного водителя и карту его движения
- •Следить за статусом поездки от подачи до завершения
- •Оплатить поездку и оставить отзыв после завершения
Путь водителя
- •Выйти в онлайн или офлайн и публиковать координаты
- •Получать запросы на поездку и принимать или отклонять их
- •Строить маршрут к точке подачи и к пункту назначения
- •Передавать статусы поездки и завершать её в приложении
- •Получать оплату и видеть историю выполненных поездок
2Нефункциональные требования
Низкая задержка
Подбор водителя должен укладываться примерно в минуту, а обновление карты не может запаздывать на десятки секунд.
Высокая доступность
Люди зависят от сервиса в дороге, поэтому запрос поездки, навигация и расчёты не должны ломаться из-за локального сбоя.
Эластичность
Погода, концерты и часы пик создают резкие всплески спроса, поэтому система должна масштабироваться под сильный перекос нагрузки по зонам и времени.
Оценка нагрузки
3Поток координат в реальном времени
Связанная тема
Геоиндексация
Подходы к пространственному индексу и поиску по карте удобно сравнивать с кейсом Airbnb.
⚠️ Главная сложность
Миллион водителей, которые отправляют координаты каждые 3-4 секунды, быстро дают сотни тысяч записей в секунду. Для такого потока нельзя опираться только на традиционную транзакционную базу данных.
Контур координат обычно держат в памяти и страхуют коротким окном : если приложение водителя перестало присылать новые точки, система сама снимает его с карты доступных кандидатов.
Сервис координат водителей
- •Принимает поток координат от приложений водителей
- •Держит актуальное положение в памяти, например в Redis
- •Помечает водителя как офлайн, если обновления пропали
- •Публикует поток в Kafka для истории, аналитики и зависимых сервисов
Пространственный индекс
Для быстрого поиска ближайших водителей обычно используют geo-команды Redis, Geohash или H3.
# Redis GEO commands
GEOADD drivers {lng} {lat} driver_123
GEORADIUS drivers {lng} {lat} 5 km
WITHDIST WITHCOORD COUNT 10
# Или Geohash подход
SET driver:123:location "9q8yy"
SMEMBERS geohash:9q8yy:driversWikipedia
Geohash
Подход к кодированию координат в строку для пространственного индексирования.
Поток обработки координат
- 1Приложение водителя передаёт координаты через WebSocket или UDP
- 2Шлюз принимает поток и сглаживает всплески записи батчами
- 3Redis Cluster хранит текущие координаты и геоиндекс доступных водителей
- 4Kafka получает поток для истории поездок, аналитики и расчёта спроса
4Подбор водителя и пассажира
Ключевой путь здесь — это : система должна быстро найти ближайших кандидатов, а затем применить , чтобы выбрать водителя не только по расстоянию, но и по вероятности успешного принятия поездки.
Как проходит назначение поездки
- 1Пассажир создаёт запрос поездки
Точка подачи, пункт назначения и тип поездки попадают в шлюз API.
- 2Сервис диспетчеризации собирает кандидатов
Из геоиндекса выбираются ближайшие свободные водители с нужным типом автомобиля.
- 3Кандидаты ранжируются
Учитываются ожидаемое время подачи, рейтинг, история принятия заказов и текущая траектория движения.
- 4Лучшему кандидату отправляется оффер
Push-уведомление или сокетное сообщение живёт ограниченное время, обычно 15-30 секунд.
- 5При отказе система выбирает следующего
Так контур назначения остаётся быстрым даже при низкой доле принятых офферов.
Последовательное назначение
Оффер уходит одному лучшему кандидату, и система ждёт ответа перед следующей попыткой.
- + Проще объяснить и реализовать
- + Меньше конкуренции между водителями
- - Медленнее при отказах и молчании
Пакетная рассылка
Оффер рассылается сразу нескольким кандидатам, и заказ получает первый принявший.
- + Снижает время до назначения
- - Повышает конкуренцию между водителями
- - Сложнее контролировать справедливость выдачи
Перераспределение предложения
Чтобы заранее сглаживать перекос спроса, система показывает водителям зоны высокого спроса и стимулирует смещение туда ещё до нового заказа.
- •Прогноз спроса: модели учитывают время суток, погоду и городские события
- •Текущее предложение: система видит распределение активных водителей по зонам
- •Стимулы: бонусы и повышенные тарифы помогают подтянуть водителей туда, где возник дефицит
5Расчёт времени и маршрута
Оптимизация
Кэширование прогноза времени
Популярные маршруты и повторяющиеся пары зон можно кэшировать по аналогии с подходом сетей доставки контента.
Для пользователя важно почти так же, как сама цена. Если прогноз подачи и маршрута систематически ошибается, сервис теряет доверие даже при идеальной диспетчеризации.
Какие прогнозы времени считает система
Время до подачи
Время от текущей позиции водителя до точки подачи. Именно его пассажир видит до подтверждения заказа и после назначения водителя.
Время поездки
Время от точки подачи до пункта назначения. Оно влияет на цену, прогноз прибытия и качество пользовательского опыта по ходу поездки.
Что влияет на расчёт
- Ограничения скорости
- Односторонние улицы
- Ограничения поворотов и проезда
- GPS-данные активных водителей
- Пробки и аварии
- Временные ограничения по маршруту
- День недели и время суток
- Сезонность и повторяющиеся паттерны
- Систематические ошибки прошлых прогнозов
Маршрутизатор
Внутри Uber-подобной системы отдельный маршрутизатор решает, какой путь считать базовым, а какой — корректировать на лету.
- •Contraction Hierarchies: ускоряют запросы по большому дорожному графу
- •A*: удобен для локального поиска маршрута с учётом текущей обстановки
- •ML-коррекция: правит систематические ошибки прогноза на основе истории
6Динамическая надбавка к цене
Uber Engineering
H3: Hexagonal Hierarchical Index
Open-source библиотека Uber для геопространственного индексирования на гексагональной сетке.
Логика нужна не для того, чтобы просто поднять тариф. Она помогает выровнять спрос и предложение по зонам и минутам, когда свободных машин становится слишком мало.
Зачем нужна надбавка
Со стороны спроса
Более высокая цена снижает число несрочных заказов и освобождает машины для тех пользователей, которым поездка действительно нужна сейчас.
Со стороны предложения
Более высокая цена привлекает водителей в дефицитные зоны и помогает быстрее восстановить баланс предложения.
Пример расчёта множителя
# Упрощённая формула
surge_multiplier = demand / supply
# Где:
# demand = ride_requests в зоне за последние N минут
# supply = available_drivers в зоне
# Пример зон (Geohash или H3 cells)
zone_9q8yy:
demand: 50 requests/5min
supply: 10 drivers
surge: 5.0x → cap at 3.0x
# Надбавка применяется к базовому тарифу
final_price = base_fare * surge_multiplierЦеновые зоны
- •Город делят на H3-ячейки или похожие геозоны
- •Для каждой зоны считают собственный множитель надбавки
- •Пересчёт выполняется каждые 1-2 минуты
- •Переходы между соседними зонами сглаживают, чтобы цена не прыгала хаотично
Фиксация цены
- •Пассажир видит цену до подтверждения поездки
- •Цена фиксируется на короткое окно, например на 5-10 минут
- •Система защищает от резкого роста цены уже после согласия пользователя
- •Для аудита и ретраев сохраняется Quote ID
7Жизненный цикл поездки
Жизненный цикл поездки удобнее всего моделировать как : у заказа есть ограниченный набор состояний, а переходы между ними должны быть предсказуемыми и идемпотентными.
Текущий этап
1. Запрос поездки
Пассажир указывает точку подачи, пункт назначения и тип поездки. Система сохраняет ценовое предложение и запускает поиск водителя.
- • Проверка зоны обслуживания и корректности точки подачи
- • Ограничение частоты запросов и антифрод-проверки
- • Quote ID и TTL для ценового предложения
Следующий переход
2. Водитель назначен
Если текущий этап завершается успешно, поездка переходит в следующее состояние автомата.
Обновления статуса в пути
Пока заказ активен, клиентское приложение должно почти без задержки видеть новые координаты и смену этапов поездки.
- •WebSocket: основной канал для живых обновлений карты и статусов
- •Push-уведомления: важные переходы, например назначение водителя или завершение поездки
- •Резервный режим: при проблемах с сокетом клиент использует на периодический опрос
Обработка отмен
- •Отмена до назначения водителя обычно остаётся бесплатной
- •Поздняя отмена пассажиром может приводить к штрафу за подачу
- •Отмена со стороны водителя влияет на его метрики и рейтинг принятия
- •Сценарий no-show требует возврата денег и отдельного аудита событий
8Высокоуровневая архитектура и сценарии
Архитектура и сценарии
Топология обработки запросов в сервисе заказа поездокКонтур запроса и диспетчеризации
Контур маршрута, цены и расчётов
Устойчивая платформа сервиса заказа поездок разводит быстрый контур координат и назначения поездки от более строгого контура цены, платежей и уведомлений. Это помогает сохранять денежных и статусных операций даже тогда, когда поток координат переживает локальный пик.
Ключевые хранилища
Геоиндекс водителей, надбавки по зонам, активные сессии и краткоживущие данные
Пользователи, поездки, платежи и другие транзакционные сущности
История координат, события поездок и длинные временные ряды
9Ключевые моменты для интервью
✓ Что стоит обсудить обязательно
- •Как обрабатывать поток из сотен тысяч обновлений координат в секунду
- •Как устроен геоиндекс и поиск ближайших кандидатов
- •Как выбирать между последовательным назначением и пакетной рассылкой офферов
- •Как считать время прибытия с учётом дорожного графа и живого трафика
- •Как динамическая надбавка выравнивает спрос и предложение по зонам
💡 Что можно добавить
- •Совместные поездки и дополнительная оптимизация маршрутов
- •Антифрод: поддельные водители, подмена GPS и аномалии в поездке
- •Функции безопасности: совместный доступ к поездке, SOS и контроль аномальных маршрутов
- •Запланированные поездки и прогноз будущего спроса
- •Мультимодальный транспорт: самокаты, велосипеды, городской транспорт
Типичные ошибки на интервью
- ✗Пытаться хранить поток координат в обычной SQL-базе без отдельного геоконтра
- ✗Не проговорить масштаб: сотни тысяч обновлений координат в секунду
- ✗Игнорировать живой трафик и накопленную ошибку в расчётах времени прибытия
- ✗Считать динамическую надбавку необязательной «бизнесовой надстройкой», а не частью архитектуры предложения
На интервью особенно важно явно проговорить ключевой : чем агрессивнее мы ускоряем назначение поездки, тем аккуратнее нужно обращаться со справедливостью выдачи, отменами и синхронизацией состояния между пассажиром и водителем.
Связанные главы
- Airbnb - Полезен для сравнения двух геодоменов: поиск кандидатов, цены и жизненный цикл заказа в двустороннем маркетплейсе.
- System Design Interview: An Insider's Guide (краткий обзор) - Помогает вспомнить базовые паттерны для геосервисов, очередей событий и масштабирования сервисов в реальном времени.
- Content Delivery Network (CDN) - Даёт полезный фон про глобальную доставку, региональные точки присутствия и снижение задержки для мобильных клиентов.
- Google Maps / Proximity Service — геопоиск - Показывает, как устроены пространственные индексы, поиск ближайших объектов и работа с географическим перекосом нагрузки.
- Hacking the System Design Interview (краткий обзор) - Полезен для упаковки архитектурного ответа и спокойного разговора о компромиссах в интервью.
- Примеры задач по системному дизайну - Ставит кейс Uber/Lyft в общий контекст соседних системных дизайн-задач и продуктовых ограничений.
- Краткосрочная подготовка к интервью по системному дизайну - Помогает превратить эту архитектуру в короткий и убедительный ответ под ограничение по времени.