π Uber - Ride Request Service
Uber wants to optimize its ride dispatching algorithm.
Project Overview
Uber wants to optimize its ride dispatching algorithm.
This is the final microservice that brings everything together in our Uber Microservices Project. The Ride Request Service is responsible for handling ride requests, matching passengers with drivers, calculating fares, and managing ride statuses.
This service relies on the previous uber microservices we saw:
Uber Driver Management Service β Finds available drivers and updates driver statuses.
Uber Surge Pricing Service β Retrieves surge multipliers for real-time fare adjustments.
It also relies on an external microservice that we have not coded but is made available to us:
Uber Traffic Data Service β Provides estimated travel times based on traffic conditions.
Read the uber project microservices overview beforehand to understand how this fits in the architecture of the entire microservice.
Your submissions
No submissions yet, start by making your first submission
Detailed Project Description
Read the uber project microservices overview beforehand to understand how this fits in the architecture of the entire microservice.
π Uber Ride Request Service - Project Statement
π Project Overview
This is the final microservice that brings everything together in our Uber Microservices Project. The Ride Request Service is responsible for handling ride requests, matching passengers with drivers, calculating fares, and managing ride statuses.
This service relies on the other microservices we saw in the previous chapters:
- Uber Driver Management Service (
http://localhost:5003
) β Finds available drivers and updates driver statuses. - Uber Surge Pricing Service (
http://localhost:5001
) β Retrieves surge multipliers for real-time fare adjustments. - Uber Traffic Data Service (
http://localhost:5002
) β Provides estimated travel times based on traffic conditions.
When your submission is executed, it will have access to a correct implementation of these services running on their respective ports. Your task is to implement the Ride Request Service so that it properly interacts with these services to facilitate ride matching, fare calculation, and ride lifecycle management.
π Required API Endpoints & Behavior
- Your API should run on the port 5000.
1οΈβ£ Request a Ride
- Endpoint:
POST /rides
- Description: Requests a ride for a user by finding an available driver and calculating the estimated fare.
- Request Body:
{ "user_id": "12345", "pickup_location": { "lat": 40.7128, "lng": -74.006 }, "dropoff_location": { "lat": 40.7306, "lng": -73.9352 } }
- Expected Response:
{ "ride_id": "a1b2c3d4-e5f6-7890", "user_id": "12345", "driver_id": "d123", "pickup_location": { "lat": 40.7128, "lng": -74.006 }, "dropoff_location": { "lat": 40.7306, "lng": -73.9352 }, "estimatedFare": 15.75, "status": "confirmed" }
- Logic:
- Fetch Surge Multiplier from
Uber Surge Pricing Service
β Adjust fare accordingly. - Fetch Traffic Data from
Uber Traffic Data Service
β Get estimated travel time. - Find an Available Driver from
Uber Driver Management Service
. - If no driver is available, return an error.
- If a driver is found, create a ride request and store it in memory.
- Return ride details including driver, estimated fare, and ride status.
- Fetch Surge Multiplier from
2οΈβ£ Get Ride Status
- Endpoint:
GET /rides/{ride_id}
- Description: Retrieves the current status of a ride.
- Expected Response (200 OK):
{ "ride_id": "a1b2c3d4-e5f6-7890", "user_id": "12345", "driver_id": "d123", "status": "confirmed" }
- Logic:
- If the
ride_id
exists, return ride details. - If not found, return 404 Not Found.
- If the
3οΈβ£ Cancel a Ride
- Endpoint:
DELETE /rides/{ride_id}
- Description: Cancels an active ride request.
- Expected Response (200 OK):
{ "message": "Ride canceled successfully" }
- Logic:
- If the ride exists, update status to
canceled
. - If the ride is already completed, prevent cancellation.
- If the ride does not exist, return 404 Not Found.
- If the ride exists, update status to
4οΈβ£ Mark Ride as Picked Up
- Endpoint:
PATCH /rides/{ride_id}/pickup
- Description: Marks the ride as picked up by the driver.
- Expected Response (200 OK):
{ "message": "Ride is now in progress" }
- Logic:
- Ensure the
ride_id
exists and has status = confirmed. - Update status to
in_progress
. - If the ride is already completed or canceled, return an error.
- Ensure the
5οΈβ£ Mark Ride as Completed
- Endpoint:
PATCH /rides/{ride_id}/complete
- Description: Marks the ride as completed.
- Expected Response (200 OK):
{ "message": "Ride completed successfully", "total_fare": 15.75 }
- Logic:
- Ensure the
ride_id
exists and has status = in_progress. - Update status to
completed
. - Return the final fare, applying the surge multiplier.
- Ensure the
βοΈ How It Works
-
User Requests a Ride:
- The Ride Request Service queries the Surge Pricing and Traffic Data Services to determine fare and estimated time.
- It then finds an available driver from the Driver Management Service.
- If a driver is available, the ride is confirmed and stored in memory.
-
Ride Lifecycle Management:
- The user can check ride status.
- If the user cancels the ride, the status updates to
canceled
. - The driver marks the ride as picked up, updating status to
in_progress
. - The driver marks the ride as completed, finalizing the fare.
-
Integration with Other Services:
- The Surge Pricing Service ensures dynamic fare adjustments based on demand.
- The Traffic Data Service provides accurate travel time estimates.
- The Driver Management Service ensures that only available drivers are assigned.
π Expected Behavior
Scenario | Expected Outcome |
---|---|
Request a ride when drivers are available | β Ride is confirmed, driver assigned. |
Request a ride when no drivers are available | β 400 No Drivers Available |
Retrieve ride status for a valid ride | β Returns ride details. |
Retrieve ride status for a non-existent ride | β 404 Ride Not Found |
Cancel a ride that exists | β Ride is canceled successfully. |
Cancel a ride that is already completed | β 400 Cannot Cancel a Completed Ride |
Mark a ride as picked up before confirmation | β 400 Cannot mark an unconfirmed ride as picked up |
Mark a ride as completed before pickup | β 400 Cannot complete a ride that has not started |
π Project Requirements
- The service must store ride requests in memory (no database).
- The system must integrate with Surge Pricing, Traffic Data, and Driver Management Services.
- Your API should run on the port 5000.
π Next Steps
- Implement the API.
- Ensure real-time communication between microservices.
- Test all endpoints for expected behavior.
π By completing this project, you will develop a fully functional ride request system that powers real-time ride-matching and pricing in a ride-sharing platform like Uber! ππ₯
Project Completion Criteria
- The system should allow users to request a ride by providing their user_id, pickup_location, and dropoff_location via the POST /rides endpoint.
- The system should fetch surge pricing data from the Uber Surge Pricing Service (http://localhost:5001) and correctly apply surge multipliers to fare calculations.
- The system should fetch real-time traffic conditions from the Uber Traffic Data Service (http://localhost:5002) to estimate trip duration.
- The system should query available drivers from the Uber Driver Management Service (http://localhost:5003) and assign a driver to the ride.
- The system should return an appropriate error message if no drivers are available when requesting a ride.
- The system should store the ride details in memory, including ride_id, user_id, driver_id, pickup_location, dropoff_location, estimated_fare, and status.
- The system should allow users to retrieve ride details using the GET /rides/{ride_id} endpoint.
- The system should allow users to cancel a ride using the DELETE /rides/{ride_id} endpoint.
- The system should prevent users from canceling a completed ride, returning an appropriate error message.
- The system should allow drivers to mark a ride as picked up using the PATCH /rides/{ride_id}/pickup endpoint, updating the ride status to "in_progress".
- The system should allow drivers to mark a ride as completed using the PATCH /rides/{ride_id}/complete endpoint, finalizing the ride and returning the total fare.
- The system should return a 404 error for any request that references a non-existent ride.
- The system should return valid JSON responses that conform to the expected request and response structures.