Проектирование Uber/Lyft — одна из самых популярных задач на System Design интервью. Это real-time система с миллионами одновременных пользователей, геолокацией, matching алгоритмами и динамическим ценообразованием.
Источник
System Design Interview
Proximity Service и Location-based системы подробно разобраны в книге Alex Xu.
Масштаб Uber
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 нагрузка. Новый год, концерты, погода.
Оценка нагрузки
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:driversWikipedia
Geohash
Алгоритм кодирования координат в строку для пространственного индексирования
Архитектура Location Service
- 1Driver app отправляет location через WebSocket или UDP
- 2Location Gateway принимает и батчит updates
- 3Redis Cluster хранит current location (geo index)
- 4Kafka stream для history и analytics
4Driver-Rider Matching
Matching Flow
- 1Rider запрашивает поездку
Pickup location, destination, ride type (UberX, Black, Pool)
- 2Dispatch Service находит кандидатов
GEORADIUS в Redis, фильтрация по ride type и status
- 3Ranking кандидатов
ETA, driver rating, acceptance rate, direction of travel
- 4Отправка запроса лучшему driver
Push notification с timeout 15-30 секунд
- 5Driver принимает или отклоняет
При отклонении — следующий кандидат
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.
Факторы расчёта
- Граф дорог
- Ограничения скорости
- Односторонние улицы
- GPS данные drivers
- Аварии, ДТП
- Пробки
- День недели
- Время суток
- Сезонность
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_multiplierSurge Zones
- •Город разбит на hexagonal cells (H3)
- •Каждая ячейка имеет свой surge multiplier
- •Обновление каждые 1-2 минуты
- •Smoothing между соседними ячейками
Price Lock
- •Rider видит цену до подтверждения
- •Цена фиксируется на 5-10 минут
- •Защита от резких скачков
- •Quote ID для отслеживания
7Trip Lifecycle
Current step
1. Requested
Rider отправляет pickup/destination и тип поездки. Система фиксирует quote и инициирует поиск водителя.
- • Валидация pickup/destination + serviceability зоны
- • Rate limits и anti-fraud checks
- • Quote ID и TTL для ценового предложения
Next transition
2. Driver Assigned
Если текущий этап завершается успешно, поездка переходит в следующий 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 systemsRequest and Dispatch Plane
ETA, Pricing and Settlement Plane
Устойчивый ride-hailing дизайн строится вокруг separation of concerns: real-time dispatch path изолирован от pricing/payment path, чтобы пик в location updates не ломал денежные операции.
Data Stores
Driver locations, surge multipliers, session data
Users, trips, payments (transactional)
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