System requirements

Functional:

Register service

• User register to this platform as passenser or driver

Ride request service

• User enter their location and destination
• User choose type of vehicle
• User choose payment method

Driver matching service

• 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

Geolocation service

• 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

Payment service

• Service calculate price based on type of vehicle and distance and time and toll-fee
• Service charge the price after arriving at destination

Chat service

• Driver and customer can chat each other after booking

Non-Functional:

Performance : service can handle high volume of concurrent request with low latency

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

Reliability : service can provide high system availability to ensure user can request reliably at any time with minimal downtime or system interruption

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

Capacity estimation

DAU : 1M

Driver : 0.1M

user action on averaging : 5

request per day : 5M

RPS : 5M/(24*60*60=86400) = 60RPS

data size per request = 500B

data size per day = 2.5G

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 list

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

• payFare(user id, trasaction id, method)

route planing service

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

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

data partitioning and sharding

Given distribued nature and high volume of ride-sharing platform like Uber, a suitable partitioning strategy would be Horizental partitioning and sharding based on geographical region where the data related to user, ride, driver are partitioned cross geographic region or cities.

This strategy ensures the data distributed evenly, optimazing query performance and scalability.

Consistent hashing algorithm can be used for sharding, which efficiently distribute the data when number of shard or nodes changes.

High-level design

FrontEnd

Driver and passenger will communicate with server using app. It connect with chat system using web socket for real time messaging between driver and passenger.

register service

It receive user's information like name, phone number, payment method and store in MySQL.

driver service

It receive driver's information like name, phone number. and driver should register their car for ride-sharing.

chat system

payment service

In this service, I assume that we use third party payment system. this service calculate price of riding using car type, time, distance and request to third party system. price would be different the amount of demand at that time. it means surge price.

matching service

It request to mongoDB to get driver near departure location. and calculate which ride would be optimal after adding this new request.

notification service

It notify to passenser whenever the status of their request is changed such like requested, matched, driver arrived, arrived, completed. and also notify to driver after matching ride to them.

route planning service

It calculate route planning from driver to passenger and from passenger to destination. It can be bounded dijkstra algorithm or A* algorithm if there's good heuristic method.

mat matching service

It received driver's location continuously using web socket. and matching it to map using Hidden Markov chain or something and store to mongoDB in order to retrieve from backend to show to the passenser. push model would be more suitable than poll model for continuous updates of location.

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