System Design Space
Граф знанийНастройки

Обновлено: 25 марта 2026 г. в 04:52

Uber/Lyft

medium

Классическая задача: real-time location, driver-rider matching, ETA calculation, surge pricing.

Uber-подобная система - это задача про живое соответствие спроса и движущегося предложения под жестким latency budget, а не просто карта с машинками.

Глава помогает разобрать location ingestion, dispatch, ETA, surge pricing, trip state machine и консистентность между rider и driver на всем ride lifecycle.

В интервью и инженерных обсуждениях кейс полезен тем, что проверяет понимание geo partitioning, state transitions и real-time matching под burst demand.

Business Correctness

Требуется корректное состояние заказа при конкурирующих запросах и ретраях.

User Experience

Надо защищать critical user flow при скачках трафика и частичных деградациях.

Transactional Boundaries

Явно задавайте, где нужна сильная консистентность, а где допустима eventual.

Evolution Path

Покажите, как архитектура растёт от MVP до multi-region масштаба.

Проектирование Uber/Lyft — одна из самых популярных задач на System Design интервью. Это real-time система с миллионами одновременных пользователей, геолокацией, matching алгоритмами и динамическим ценообразованием.

Источник

System Design Interview

Proximity Service и Location-based системы подробно разобраны в книге Alex Xu.

Читать обзор

Масштаб Uber

5M+ поездок/день
100M+ riders
10K+ городов
5M+ drivers

Uber

Uber Engineering Blog

Технические статьи о масштабировании, архитектуре и инфраструктуре Uber

Перейти на сайт

1Функциональные требования

Rider Flow

  • •Указать pickup и destination
  • •Видеть ETA и цену до подтверждения
  • •Запросить поездку и получить driver
  • •Отслеживать driver в real-time
  • •Оплатить и оставить отзыв

Driver Flow

  • •Выйти в онлайн / офлайн
  • •Получать запросы на поездку
  • •Принять или отклонить запрос
  • •Навигация к pickup и destination
  • •Завершить поездку и получить оплату

2Нефункциональные требования

Low Latency

Matching < 1 min. Location updates каждые 3-4 секунды.

High Availability

99.99% uptime. Люди зависят от сервиса для транспорта.

Scalability

Peak hours: 10x нагрузка. Новый год, концерты, погода.

Оценка нагрузки

Активных drivers:1M
Location updates/sec:~300K
Ride requests/sec:~1K
Update frequency:3-4 sec

3Real-time Location Tracking

Связанная тема

Geo-индексирование

Подходы к геопоиску (Geohash, Quadtree, S2) разобраны в кейсе Airbnb.

Читать обзор

⚠️ Главная сложность

1 миллион drivers отправляют location каждые 3-4 секунды = ~300K writes/second. Нужна специализированная архитектура.

Driver Location Service

  • •Принимает location updates от drivers
  • •Хранит в in-memory store (Redis)
  • •TTL 30 секунд — автоматический offline
  • •Публикует в Kafka для других сервисов

Geo-индексирование

Для быстрого поиска ближайших drivers:

# 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:drivers

Wikipedia

Geohash

Алгоритм кодирования координат в строку для пространственного индексирования

Перейти на сайт

Архитектура Location Service

  1. 1Driver app отправляет location через WebSocket или UDP
  2. 2Location Gateway принимает и батчит updates
  3. 3Redis Cluster хранит current location (geo index)
  4. 4Kafka stream для history и analytics

4Driver-Rider Matching

Matching Flow

  1. 1
    Rider запрашивает поездку

    Pickup location, destination, ride type (UberX, Black, Pool)

  2. 2
    Dispatch Service находит кандидатов

    GEORADIUS в Redis, фильтрация по ride type и status

  3. 3
    Ranking кандидатов

    ETA, driver rating, acceptance rate, direction of travel

  4. 4
    Отправка запроса лучшему driver

    Push notification с timeout 15-30 секунд

  5. 5
    Driver принимает или отклоняет

    При отклонении — следующий кандидат

Single Dispatch

Отправляем запрос одному лучшему driver:

  • + Простая реализация
  • + Справедливо для drivers
  • - Медленнее при отказах

Broadcast (Batch)

Отправляем нескольким drivers, первый выигрывает:

  • + Быстрее matching
  • - Конкуренция между drivers
  • - Сложнее fairness

Supply Positioning (Heat Maps)

Uber показывает drivers зоны с высоким спросом, чтобы оптимизировать распределение:

  • •Demand prediction: ML модель на основе времени, погоды, событий
  • •Supply tracking: Текущее распределение drivers по зонам
  • •Incentives: Бонусы за поездки в определённых зонах

5ETA Calculation

Оптимизация

Caching ETA

ETA для популярных маршрутов можно кэшировать по аналогии с CDN.

Читать обзор

Компоненты ETA

Pickup ETA

Время от текущей позиции driver до pickup point. Показывается rider при запросе.

Trip ETA

Время от pickup до destination. Влияет на pricing.

Факторы расчёта

Road Network
  • Граф дорог
  • Ограничения скорости
  • Односторонние улицы
Real-time Traffic
  • GPS данные drivers
  • Аварии, ДТП
  • Пробки
Historical Data
  • День недели
  • Время суток
  • Сезонность

Routing Engine

Uber использует собственный routing engine на основе:

  • •Contraction Hierarchies: Предварительная обработка графа для быстрых запросов
  • •A* algorithm: Для коротких расстояний с учётом traffic
  • •ML corrections: Корректировка на основе исторических ошибок

6Dynamic (Surge) Pricing

Uber Engineering

H3: Hexagonal Hierarchical Index

Open-source библиотека Uber для геопространственного индексирования с гексагональной сеткой

Перейти на сайт

Зачем Surge Pricing?

Demand Side

Высокая цена отсекает riders с низкой срочностью, освобождая машины для тех, кому действительно нужно.

Supply Side

Высокая цена привлекает больше drivers в зону с высоким спросом.

Расчёт Surge Multiplier

# Упрощённая формула
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

# Surge применяется к base fare
final_price = base_fare * surge_multiplier

Surge Zones

  • •Город разбит на hexagonal cells (H3)
  • •Каждая ячейка имеет свой surge multiplier
  • •Обновление каждые 1-2 минуты
  • •Smoothing между соседними ячейками

Price Lock

  • •Rider видит цену до подтверждения
  • •Цена фиксируется на 5-10 минут
  • •Защита от резких скачков
  • •Quote ID для отслеживания

7Trip Lifecycle

Запрос создан
Ride request created
Водитель назначен
Dispatch chose driver
Водитель едет
Driver heading to pickup
Водитель прибыл
At pickup point
Поездка началась
Rider onboard
Поездка завершена
Ride finished
Платеж проведен
Charge + receipt
Отменено
Отмена rider/driver до старта поездки

Текущий этап

1. Запрос создан

Rider отправляет pickup/destination и тип поездки. Система фиксирует quote и инициирует поиск водителя.

  • • Валидация pickup/destination + serviceability зоны
  • • Rate limits и anti-fraud checks
  • • Quote ID и TTL для ценового предложения

Следующий переход

2. Водитель назначен

Если текущий этап завершается успешно, поездка переходит в следующий lifecycle state.

Ветка отмены доступна на этапах Запрос создан, Водитель назначен и Водитель едет.

Real-time Updates

Rider видит driver в real-time через:

  • •WebSocket: Persistent connection для updates
  • •Push notifications: Status changes
  • •Polling fallback: Каждые 5 секунд

Cancellation Handling

  • •Rider cancels before match: бесплатно
  • •Rider cancels after 2 min: cancellation fee
  • •Driver cancels: penalty to rating
  • •Driver no-show: full refund + credits

8High-Level Architecture и стандартные сценарии

Architecture + Scenario Explorer

Real-time dispatch topology for ride-hailing systems

Request and Dispatch Plane

Rider App
ride request
API Gateway
auth + routing
Driver App
online status
Location Service
geo stream ingest
Dispatch Service
match rider-driver
Trip Service
trip lifecycle FSM

ETA, Pricing and Settlement Plane

Routing / ETA
route + traffic
Pricing Service
fare + surge
Payment Service
charge + payout
Notification
push / sms / receipt
Архитектура разделяет real-time контур (location + dispatch + trip) и transactional контур (pricing + payment + notifications).
Выбери сценарий сверху, чтобы подсветить конкретный путь обработки запроса через архитектуру Uber/Lyft.

Устойчивый ride-hailing дизайн строится вокруг separation of concerns: real-time dispatch path изолирован от pricing/payment path, чтобы пик в location updates не ломал денежные операции.

Data Stores

Redis Cluster

Driver locations, surge multipliers, session data

PostgreSQL

Users, trips, payments (transactional)

Cassandra

Location history, trip events (time-series)

9Ключевые моменты для интервью

✓ Обязательно обсудить

  • •Location tracking: как обрабатывать 300K writes/sec
  • •Geo-indexing: Geohash vs Quadtree vs H3
  • •Matching: single dispatch vs broadcast
  • •ETA: road network + real-time traffic
  • •Surge: demand/supply балансировка

💡 Дополнительные темы

  • •UberPool: групповые поездки с routing optimization
  • •Fraud detection: fake drivers, GPS spoofing
  • •Safety features: trip sharing, emergency button
  • •Scheduled rides: future demand prediction
  • •Multi-modal: bikes, scooters, transit integration

Типичные ошибки на интервью

  • ✗Хранить location в обычной SQL БД (не выдержит нагрузку)
  • ✗Забыть про масштаб: 300K location updates в секунду
  • ✗Игнорировать real-time traffic в ETA расчётах
  • ✗Не объяснить зачем нужен surge pricing

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки