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:
  1. Fetch Surge Multiplier from Uber Surge Pricing Service → Adjust fare accordingly.
  2. Fetch Traffic Data from Uber Traffic Data Service → Get estimated travel time.
  3. Find an Available Driver from Uber Driver Management Service.
  4. If no driver is available, return an error.
  5. If a driver is found, create a ride request and store it in memory.
  6. Return ride details including driver, estimated fare, and ride status.

---

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.

---

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.

---

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.

---

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.

---

⚙️ How It Works

1. 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.

2. 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.

3. 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

1. Implement the API.
2. Ensure real-time communication between microservices.
3. 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! 🚖🔥