Car Pooling Service
Design a car-pooling service matching drivers and passengers by proximity — nearby search, nearest-ride booking with fallback, and a concurrency follow-up.
Design an in-memory car-pooling service that manages ride offers and bookings between drivers and passengers. All coordinates are given as latitude and longitude in floating point numbers.
This one tests whether you can combine geometric proximity search with stateful booking logic cleanly — nearest-ride selection, seat-capacity bookkeeping, and idempotent ride creation — while staying ready to reason about concurrency out loud when the interviewer pushes on it.
For distance checks, treat the Earth as a flat plane and apply the Euclidean distance formula between two (lat, lng) points — no need for the Haversine formula or real great-circle distance. A ride counts as nearby if the straight-line distance between the driver's start point and the passenger's requested start point is ≤ 5 km.
Objective
The primary objective of this project is to design and implement an in-memory service where drivers register rides with seat capacity, passengers discover nearby rides sorted by distance, bookings decrement seats with a fallback to the next-nearest ride when one is full, and cancellations and ride history are tracked correctly per passenger.
Functional Requirements
Requirements are split into two tiers so you know what to prioritize under time pressure: build first, and worth proposing if time allows.
Part 1 — Core Operations
Core functionality you must build and get working first.
A duplicate rideId on Add ride must be rejected or ignored — the system must stay idempotent. On Book the nearest ride, if the requested ride's seat is full, the system should report that it's unable to book that ride and automatically fall back to the next-nearest ride that still has an available seat.
Part 2 — Suggested Extensions
These extend naturally from the core five operations and are the kind of follow-up an interviewer is likely to ask about once the basics work.
Follow-Up Question: Concurrent Booking
Describe a locking, optimistic-concurrency, or compare-and-swap approach.
Example Usage: Full Walkthrough
Here's how a sample session might run end-to-end, one step at a time.
1. Add a ride
> addRide(startLat: 12.90, startLng: 77.60, endLat: 12.95, endLng: 77.65, driverName: "Ravi", maxSeatCapacity: 2)
✅ Ride r1 added. Driver: Ravi. Seats available: 2.
2. Find nearby rides for a passenger
> findNearbyRides(personName: "Alice", startLat: 12.905, startLng: 77.602, endLat: 12.95, endLng: 77.66)
📍 Nearby rides (within 5 km), sorted by distance:
- r1 Ravi distance: 0.6 km seats available: 2
3. Book the nearest ride
> bookNearestRide(personName: "Alice", rideId: "r1")
✅ Alice booked ride r1. Seats remaining: 1.
4. A second and third passenger book the same ride — one hits the fallback
> bookNearestRide(personName: "Bob", rideId: "r1")
✅ Bob booked ride r1. Seats remaining: 0.
> bookNearestRide(personName: "Carla", rideId: "r1")
❌ Ride r1 is full. Falling back to next-nearest ride with availability...
✅ Carla booked ride r2. Seats remaining: 1.
5. Cancel a booking
> cancelRide(rideId: "r1", personName: "Bob")
✅ Bob's booking on ride r1 canceled. Seats remaining: 1.
6. Check a passenger's ride history
> getRideHistory(personId: "alice-id")
🧾 Ride history for Alice:
- r1 Ravi booked at step 3
Alice books the nearest ride outright; Bob fills the last seat; Carla's attempt on the same full ride correctly falls back to the next-nearest ride with space. Canceling Bob's booking frees a seat on r1 without disturbing Alice's or Carla's separate bookings.
Guidelines
This is a 90-minute round with the interviewer present. Code is written and executed on HackerRank, and will be tested against input the interviewer provides directly — so the solution needs to run correctly as a standalone program, not just look right on paper.