A Cab Booking System is a service provider that allows users to book a ride from their computer or phone. Users can select the kind of cab they want, enter their pickup and destination, and request a ride. The system will then find a nearby available driver and send the driver to pick up the user. Users can also see the estimated fare and track the cab in real time. A Cab Booking System allows customers to simply schedule trips, check estimated arrival times, and receive ride notifications.

Requirements Gathering for the Cab Booking System

Functional Requirements for the Cab Booking System:

• Book a Ride: Users may reserve a cab by entering their pickup and drop-off locations. They can select the sort of  cab they like.
• Check Cab Availability: The system searches for available taxis near the user’s location.
• Assign Driver: When the user requests a ride, the system assigns an available driver.
• Track Ride: Users may see the cab’s real-time location on the map.
• Calculate fee: The system estimates the fee depending on the distance and kind of cab.
• Payment Processing: Users can pay for the ride with a variety of methods (such as credit card or digital wallet).
• Rate and Review: Users can rate and review the driver after the ride is completed.
• Ride History: Users can view their past ride history including details of each ride.
• Notifications: Users receive notifications about ride status (e.g., cab arrival, ride start, ride end).
• Cancel Ride: Users can cancel a ride before it starts.

Non-Functional Requirements for the Cab Booking System:

• High Availability: The system should be available at all times without significant downtime. Ensures continuous service with minimal interruptions.
• Low Latency: The system should react instantly to ride requests and updates. Provides fast and efficient service to users.
• Scalability: It refers to the system’s capacity to manage a high number of users and ride requests at once. Supports expansion and high demand without compromising the performance.
• Security: The system should protect user data and payment information. It should safeguard critical information from unauthorized access.
• Durable Storage: The system should be capable of storing user data and ride history. Maintains data integrity and availability throughout time.

Memory and Estimations for the Cab Booking System

Let’s start with the estimation and constraints because these things help us to make better design decisions that’s why we do estimations along with the requirement gathering.

Assumptions for the Cab Booking System:

• User Base: Let’s assume the system is designed for 50M users.
• Active Users: Out of all these users, 1/5 are actively booking rides.
• Rides per Day: Assuming each active user books 2 rides per day.

So, the number of rides per day = 10M (active users) * 2 = 20M rides/day

• Storage for 1 ride = { Ride details + user ID + driver ID + location data + fare }= 2 KB
• Total storage per day = 2 KB * 20M = 40,000,000 KB = 40 GB/day

Storage for 1 year = 40 GB/day * 365 = 14.6 TB/year

Low-Level Design for Cab Booking System

Uber and other taxi services are familiar worldwide. Through the application, a user can request a ride, and a driver will come to their location to take them to their destination in a matter of minutes.

• Cab services were first developed using a “monolithic” software architectural paradigm. They just had one database, one frontend service, and one backend service. As the ORM layer for the database, they employed SQLAlchemy, Python, and its frameworks.
• This architecture was adequate for a few trips in a limited number of cities. But as the service spread to further cities, scalability problems arose with the program.

1. Challenges

The main task of a cab booking service is to match riders with cabs, requiring two distinct services in the architecture:

• Supply Service (for cabs)
• Demand Service (for riders)

The dispatch system matches supply with demand. This system uses mobile phones to match drivers with riders (supply to demand).

2. Supply Service

Cabs (supply) are tracked by geolocation (latitude and longitude). Active cabs send their location to the server every 4 seconds via a web application firewall and load balancer. The accurate GPS location is sent to the data center through Kafka’s Rest APIs. Apache Kafka acts as the data hub, updating the latest location in the system. Additionally, details like the number of seats, car seat availability, vehicle type, and occupancy are tracked.

3. Demand Service

The demand service receives cab requests via a web socket, tracking the GPS location of the user and their requirements (e.g., number of seats, type of car). It then requests cabs from the supply service.

4. Matching Riders to Drivers

Sharding keys are used by the dispatch system in small cells with unique IDs. Location is shifted by the cell ID whenever a request comes through the supply service from demand service. These cells are managed by servers situated in different regions filtering nearby cabs that the rider’s requirements fulfill. Rather than the geographical distance, ETA is based on the road distance, and a list of available cabs sent back to the supply system for driver assignment.

5. Map Regions

Prior to entering any new region, you must first add it into the map technology stack. These are the type of regions:

• Grade A(City): These are city centres and commuting zones which have 90% traffic and require the best maps.
• Grade B(Rural & Suburban): Rural and suburban areas with low population density and also few vehicles.
• Grade AB(City +Rural+Suburban): Combination of grade A and B regions.
• Grade C(Highway regions): Corridors of highways that link different territories together.

6. Map Building

The maps used by cab companies are constructed with the help of an external mapping service. At first, this was done using Mapbox; however, it was changed to the Google Maps API in order to make it more precise when tracking a location or calculating the estimated time of arrival (ETA).

• Trace Coverage service: This is where we find out which roads do not appear on the map or are wrongly shaped by comparing them with historical GPS traces of rides.
• Pickup Point Accuracy ratio: While dealing with big places such as airfields and stadiums, it is important to know the exact pickup points so that drivers can be directed easily through the shortest routes.

7. ETA Calculation

ETA calculation is critical as it impacts ride-matching and earnings. Factors like traffic and road construction are considered, identifying not only free cabs but also those about to finish a ride. The road network is represented as a graph, with nodes as intersections and edges as road segments. Dijkstra’s algorithm or AI-simulated algorithms determine the best route, considering additional factors like one-way streets, turn costs, and speed limits. OSRM (Open Source Routing Machine) ensures faster performance.

This low-level design ensures efficient matching of riders to drivers, scalable dispatch operations, and accurate ETAs for a seamless cab booking experience.

Database Design for the Cab Booking System

1. Tables:

• Users: Stores user information (user_id, name, email, phone, etc.)
• Drivers: Stores driver information (driver_id, name, email, phone, cab details, etc.)
• Rides: Stores ride details (ride_id, user_id, driver_id, pickup_location, dropoff_location, fare, status, etc.)
• Payments: Stores payment information (payment_id, ride_id, user_id, amount, payment_method, status, etc.)
• Ratings: Stores ride ratings and reviews (rating_id, ride_id, user_id, driver_id, rating, review, etc.)

2. API Design of the System

2.1. Display Info for Each User:

Stores user information (user_id, name, email, phone, etc.)

@GET /api/users/{userId}

2.2. Get Rides for the User:

Stores driver information (driver_id, name, email, phone, cab details, etc.)

@GET /api/users/{userId}/rides
{
date: currentDate,
days: 7
}

2.3. Book a Ride:

Stores ride details (ride_id, user_id, driver_id, pickup_location, dropoff_location, fare, status, etc.)

@POST /api/users/{userId}/rides
{
pickupLocation: "location",
dropoffLocation: "location",
cabType: "type",
paymentMethod: "method"
}

2.4. Cancel a Ride:

checks the payment status and then cancel the raid.

@PUT /api/users/{userId}/rides/{rideId}/cancel

2.5. Rate a Ride:

Stores ride ratings and reviews (rating_id, ride_id, user_id, driver_id, rating, review, etc.)

@POST /api/users/{userId}/rides/{rideId}/rate
{
rating: 5,
review: "SMOOTH AND SAFE RIDE!!!"
}

Database Model for the Cab Booking System

A database model for a cab booking system is crucial as it helps in managing all the different parts of the system well. Below are descriptions of each table with regards to the cab booking system:

• The Users (Schema) contain all the necessary details which are about the every rider and driver. Its each element has a unique id and their personal information like name email and phone number. Also the indication whether he is a rider or a driver shows what service the person can get from the system.
• The Cabs (Schema) maintains details of the cabs that are available. The table contains the identifier for every taxi, its enrollment number, type of car and capacity. This is useful for control and monitoring of taxis’ fleets.
• The Trips(Schema) records every single ride demand. It Includes specifics about who requested the ride, the driver who accepted it, the car that was used, pick-up and drop-off locations, the ride’s status, and timestamps for the beginning as well as conclusion of each trips. Essentially, this chart is essential when it comes to keeping track of historical data concerning trips.
• The Payments (Schema) keeps track of payments made for rides. It records all payment transactions tied to a trip – payment ID, ride ID, amount paid, payment method and payment status. This table is used for financial monitoring and balancing of accounts.
• The Ratings (Schema) captures feedback from riders about their ride experience. It includes the ride ID, rider’s rating, and optional comments. This table helps maintain the quality of service by monitoring driver performance and rider satisfaction.

Microservices used for the Cab Booking System

Microservices used in Cab Booking System are:-

• Ride Booking Microservice: Handles ride requests and assignments.
• Payment Microservice: Handles payment processing.
• Notification Microservice: Sends notifications to users about ride status.
• Rating Microservice: Handles ride ratings and reviews.

Conclusion

In conclusion, you need to think about many different parts and characteristics that are vital for making a Cab Booking System easy to use. For example, it should be able to grow as more people start using , It means that the system needs to be scalable. In addition, such systems must also be safe and secure so that they will not cause any harm or danger the person using them while operating. Besides handling large amounts of requests at once very quickly, this type of program has other features like saving information about users (such as where they live) securely alongside processing their payments effectively.