Clone Design

Workflow of our application

The following steps show the working of our application.

1. The passenger enters the dropoff location and requests a ride.

2. Until a matching driver is found, the status will be “waiting for the driver to respond.”

3. On the other hand, the driver reports his location every 4 seconds. The application finds the trip information and returns it to the driver.

4. The driver accepts or rejects the request.

   4.1 The driver accepts the taxi request. Modify the status information. The passenger finds that he is successfully matched and obtains the driver’s information.

   4.2 The driver refuses the ride request. Modify the status information to mark that the driver has rejected the trip. Re-match a driver and restart from step 2.

High-level design

We have already discussed the basic building blocks needed to make the Uber application. Let’s use these building blocks to build our application at a higher level according to our workflow and requirements.

• Server 1: This server will take ride requests from the passengers and receive nearby drivers’ information from the second server. A driver will be matched with a passenger here, and it will send the trip information containing driver information to the passenger and the database.
• Server 2: It will constantly receive the driver’s location information and save them in the database. It will also send the nearby driver’s information to the first server.
• Database: This will contain all the completed trips and driver’s locations.

Detailed design

It’s time to look at the system and see how the various components work together to offer overall functioning. We’ll go through several additional ...