Ride hailing looks like a simple marketplace: a rider asks for a car, a nearby driver accepts. What makes it hard is that every participant is moving. A million drivers send their position every few seconds, the "nearest car" changes while you're computing it, and two riders must never be matched to the same driver.
Module 10 had a lab that sketched a ride-hailing app from a blank page. This one goes deeper, at real scale: location ingest, the geo index, matching and the trip lifecycle.
The brief
You're building the core of a ride-hailing service like Uber. A rider opens the app, sees cars nearby, requests a ride, gets matched to a driver within seconds, watches the car approach, takes the trip and pays.
Who uses it?
- Riders open the app, often in a hurry, often in a crowd (a stadium letting out, a station at rush hour).
- Drivers keep the app open for hours while driving. Their phones send location constantly over mobile networks that drop in and out.
- Operations teams in each city watch supply and demand.
In scope: driver location updates, showing nearby cars, requesting a ride, matching, the trip lifecycle from request to completion, and live tracking during the trip.
Out of scope: pricing and surge calculation (we'll assume a pricing service gives a fare), payments (see the Razorpay lab), routing and ETA computation (see the Google Maps lab; we'll call an ETA service), ratings, and pooled rides.
Requirements
Functional
- Drivers go online and offline. Online drivers send their location every ~4 seconds.
- Riders see nearby available cars on a map.
- A rider requests a ride from A to B. The system finds a driver, offers the ride, and the driver accepts or declines.
- Both sides see each other's live location once matched.
- The trip moves through clear states: requested, matched, driver arriving, in progress, completed, or cancelled.
Non-functional
- Matching is fast: a rider gets a driver within ~10 seconds when supply exists.
- No double booking: a driver is never matched to two trips at once.
- Location is fresh: the location used for matching is at most a few seconds old.
- Highly available: a region or city must keep working if a single node fails. A dead dispatch system means drivers earn nothing and riders are stranded.
- Trips are durable: a trip's record and state are never lost, because money depends on them.
Notice the split. Locations are high-volume, short-lived and disposable: a location from 30 seconds ago is worthless. Trips are low-volume, long-lived and precious. They need different storage.