In this series of popular system designs, I will take up design for a taxi aggregator service like Uber. Please note that the designs I share are based on my understanding of these systems and might not be the same as actual designs.
Before Getting on with Designs, let’s list down the requirements
Functional Requirements
- User (Rider) should be able to create an account
- Driver should be able to register
- Rider should be able to view cabs availability in near proximity along with approx ETA
- Rider should be able to request for a cab
- Driver should be able to receive a trip request.
- Driver can accept the request (Assumption: Multiple drivers will receive the request and one will accept)
- Trip starts when rider boards the request.
- When trip ends, Rider can make the payment and receive a receipt.
- Rider can rate the Trip / Driver
- Rider can view Trip history
- Driver can view Trip history
Non Functional Requirements
- Availability
- Scalability
- Performance
- Consistency
- Localization
Services to be created
- User Management Service
- Driver Management Service
- Cab Search Service (Takes Riders location and finds nearby cars)
- Ride Request Service (Rider’s request is shared with drivers for acceptance)
- Trip Management Service
- Trip History Service
Database Requirements
- User Data
- Driver and Cab Data
- Cab Location Data
- Trip Data (Current and Historical)
A high-level design might look like
An important question one needs to answer is about the Cab locator service works. The class way of GeoHashing should be used, where the whole area will be thought of as square boxes. Say a user is at Lat, Long position, we will try to find all the boxes around the current location within a given radius. And then find all the Drivers available in these Geo boxes.
Some interesting alternative representations
