System requirements

Functional:

• User enter their location and destination
• User choose type of vehicle
• User choose payment method
• Service find available driver around pickup location
  • available driver means which has no or ride sharing passenser
  • in case ride sharing, Service will filter big distance between exsiting route plan and new destination
• If there's no available driver, Service notify it to customer to retry
• Service provide route plan from driver's location to pickup location for driver who accept the request
• Driver notify that he pick up the user
• Service calculate price based on type of vehicle and distance and time and toll-fee
• Service charge the price after arriving at destination

Non-Functional:

Strong consistency : driver and user should see same data.

Compliance : the location data should be separated with user's identification data

Availability

Scalability : User and driver and call would be getting more and more

Capacity estimation

DAU : 50M

HAU on peak hours : 40M

Driver : 40M

Call on peak hours : 40M

payment : 50M*256B = 5.12G/day

API design

driver matching service : find available driver near customer

• findAvailableDriver(Location destination, int radius, Vehicle type) -> Driver

Notification service

Pricing service : calculate price

• calculatePrice(Vehicle type, Long distance, Long weight)
• getWeight -> Long weight for now

map matching service : matching location of driver and customer to map

• mapMatching(GPS location) -> Location location

payment service

route planing service

• routePlaning(Location start, Location destination, Location[] stops) -> Link[] route plan

driver service : register driver and vehicle

• registDriver(Profile profile, Vehicle vehicle) -> Success or Fail

HTTP error code will be used

Database design

[Driver] index(location, vehicle_type)

• id int, primary key
• location point
• vehicle_type enum
• address
• plate_number

[Customer]

• id int, primary key
• location point
• phone_number String

[Call]

• id int, primary key
• driver_id
• customer_id
• vehicle_type enum
• passanser_count int
• ride_at timestamp
• drop_off_at timestamp
• status enum(requested, failed, canceled, matched, completed)

[Route_Plan]

• id int, primary key
• call_id
• route json_string

[payment]

• id int, primary key
• method string
• paid boolean
• total_price long
• user_id int
• call_id int

High-level design

Request flows

Detailed component design

• map_matching algorithm : hidden markov chain would be good for this
• driver matching : using spatial query in postgres is simple implementation. implementing contains query for points after loading data can be chosen for some situations.
  • If customer cancel the call after matching driver, this will change the status of call to Canceled
  • If there's no available driver for the call, this will change the status of call to Failed
• route planning algorithm : A* algorithm is good for latency. dijkstra algorithm is slow for this service.

Trade offs/Tech choices

RDBMS vs NoSQL : strong consistency is important for this service. RDBMS would be more good for this.

Failure scenarios/bottlenecks

DB failure : db can be break down. we can duplicate and make replication. and using circuit breaker service can be stable.

Future improvements