logo
System Design Case Studies

Design Uber

case study: Uber

我们来设计一个类似 Uber 的网约车服务,对标 LyftOLA Cabs

What is Uber?

Uber 是出行平台,用户叫车、司机接单并完成行程,支持 web 与移动端。

Requirements

Functional requirements

两类用户:Customers 与 Drivers。

Customers

  • 查看附近车辆、ETA 与价格
  • 预约/下单
  • 查看司机位置

Drivers

  • 接单或拒单
  • 查看接客位置
  • 到达后完成行程

Non-Functional requirements

  • 高 reliability
  • 高 availability,低 latency
  • 可扩展、高效

Extended requirements

  • 评价
  • 支付
  • Metrics & analytics

Estimation and Constraints

注意:和面试官确认规模假设。

Traffic

假设 100M DAU、1M drivers、10M rides/day。每个用户 10 次动作 => 1B requests/day:

$$ 100 \space million \times 10 \space actions = 1 \space billion/day $$

RPS

$$ \frac{1 \space billion}{(24 \space hrs \times 3600 \space seconds)} = \sim 12K \space requests/second $$

Storage

每条 400 bytes:

$$ 1 \space billion \times 400 \space bytes = \sim 400 \space GB/day $$

10 年约 1.4 PB:

$$ 400 \space GB \times 10 \space years \times 365 \space days = \sim 1.4 \space PB $$

Bandwidth

$$ \frac{400 \space GB}{(24 \space hrs \times 3600 \space seconds)} = \sim 5 \space MB/second $$

High-level estimate

TypeEstimate
Daily active users (DAU)100 million
Requests per second (RPS)12K/s
Storage (per day)~400 GB
Storage (10 years)~1.4 PB
Bandwidth~5 MB/s

Data model design

uber-datamodel

customers:用户

drivers:司机

trips:行程

cabs:车辆信息

ratings:评分

payments:支付

选什么 database?

建议拆成多服务,各自拥有表,避免单库瓶颈。可用 PostgreSQLApache Cassandra

API design

Request a Ride

requestRide(customerID: UUID, source: Tuple<float>, destination: Tuple<float>, cabType: Enum<string>, paymentMethod: Enum<string>): Ride

Cancel the Ride

cancelRide(customerID: UUID, reason?: string): boolean

Accept / Deny

acceptRide(driverID: UUID, rideID: UUID): boolean
denyRide(driverID: UUID, rideID: UUID): boolean

Start / End Trip

startTrip(driverID: UUID, tripID: UUID): boolean
endTrip(driverID: UUID, tripID: UUID): boolean

Rate the Trip

rateTrip(customerID: UUID, tripID: UUID, rating: int, feedback?: string): boolean

High-level design

Architecture

采用 microservices

Customer Service:客户信息

Driver Service:司机信息

Ride Service:匹配 + quadtree

Trip Service:行程管理

Payment Service:支付

Notification Service:通知

Analytics Service:指标分析

Inter-service communication

REST/HTTP 或 gRPC,配合 Service discovery

How it works

uber-working

  1. 用户发起请求
  2. Ride service 找附近司机 + ETA
  3. 广播给司机
  4. 司机接单后推送位置
  5. 开始行程
  6. 完成行程并收款
  7. 用户评价

Location Tracking

Pull model:Long polling

Push model:WebSockets / SSE(推荐 WebSockets)

后台需有 GPS ping。

Ride Matching

SQL:范围查询,scale 差

Geohashing:用 geohash 索引

Quadtrees:范围查询高效

结合 Redis 缓存位置。用 Hilbert curve 提升 range query。

Race conditions

Mutex + transactions 保障一致性。

Best drivers

按 rating/反馈做排序。

High demand

用 Surge Pricing。

Payments

StripePayPal + webhook。

Notifications

Kafka / message queue + FCM/APNS。

Detailed design

Data Partitioning

按区域/分片存储,配合 Sharding + Consistent hashing

Metrics and Analytics

Apache Spark

Caching

缓存司机/乘客位置,LRU eviction。

Identify and resolve bottlenecks

uber-advanced-design

提升 resilience:多实例、load balancers、DB replicas、分布式 cache 多副本、Kafka/NATS。

相关练习题

Design Uber

暂无相关练习题