System requirements

Functional:

• User register to this platform as passenser or driver
• 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
• Driver and customer can chat each other after booking

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 : 1M

Driver : 0.1M

request per day : 0.5M

RPS : 0.5M/(24*60*60=86400) = 6RPS

data size per request = 512B

data size per day = 250M

API design

Register Service : register as driver or passenser

• registerAsDriver(name, phoneNumber, plateNumber, carType)
• registerAsPassenser(name,phone Number, Payment method)

driver matching service : find available driver near customer

• findAvailableDriver(Location destination, int radius, Vehicle type) -> Driver or notify to passenser for fail

Notification service

• notifyStatus(user id, ride status)

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

tech choice

driver

• choice : MongoDB
• reason : availability is more important for location of driver.

customer

• choice : MySQL or MongoDB
• reason : depends on Scalability, We can choose MySQL or MongoDB

payment

• choice : MySQL
• reason : consistency is crucial for finance domain

call

• choice : MySQL or MongoDB
• reason : depends on Scalability, We can choose MySQL or MongoDB

routeplan

• choice : MongoDB
• reason : flexable data type for logging

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