Uber ETA & Location Sharing

What is being asked

Design the location and ETA side of a ride app: drivers report position continuously; riders see their driver move and an arrival time that stays accurate.

Requirements

Functional

• Ingest driver locations every few seconds.
• Find drivers near a point.
• Stream a driver's position to the matched rider; compute and update the ETA.

Non-functional

• Write-heavy: millions of updates a second at peak.
• Recent positions matter; old ones are only for history and billing.
• Low latency on the rider's map.

Design

1. The driver app sends batched positions over a persistent connection.
2. The latest position of each driver is kept in an in-memory spatial index, where the map is cut into cells (geohash or hexagons) and each cell lists its drivers. "Nearby" becomes a lookup of a cell and its neighbours.
3. For an active trip, the tracker pushes the driver's position to the rider over the rider's own connection.
4. The ETA service snaps positions to roads and computes travel time on a road graph weighted by current traffic, itself derived from the same location stream.
5. All positions are also written to cheap storage for fare calculation and disputes.

Key decisions and trade-offs

• Only the latest position needs to be fast. Keep it in memory with a short expiry; a driver whose updates stop simply disappears from the index.
• Cell-based index over a database query. Geohash or hexagon cells make the index shardable by region and updates constant-time.
• Update frequency. Every 4 seconds gives a smooth map but four times the load of every 15; adapt the rate to whether the driver is on a trip.
• ETA accuracy depends more on live traffic and map matching than on the routing algorithm.

Follow-up questions

• How do you smooth a GPS trace that jumps across a river?
• How would you handle a city where one cell holds ten thousand drivers?
• What if the rider loses connectivity for a minute?
• How do you precompute routes to answer ETAs in milliseconds?