Case Study 6: Uber / Swiggy Ride and Food Delivery

Match a customer to the nearest driver/delivery partner using real-time location tracking, and provide ETA and surge pricing.

C.1 Requirements

Functional requirements:

• The driver/delivery partner sends their live location every 4-5 seconds.
• A rider requests a ride or a customer places a food order.
• Find the nearest available driver and send a ride/order offer (accept/reject).
• Show the ETA and fare estimate for pickup and drop.
• Apply surge pricing when demand is high and supply is low.
• Order/trip state machine: requested -> assigned -> picked up -> delivered/completed.
• Live tracking on a map, payment and rating.

Non-functional requirements:

• Matching latency < 2-3 seconds, location update ingestion < 1 second.
• Strong consistency for trip/order and payment: one driver must not be assigned to two rides.
• Eventual consistency is OK for location data (a 2-5 sec old location is fine).
• Availability 99.99%: it must work at peaks too (lunch/dinner, rain, New Year).
• Scale: 50 lakh (5 million) online drivers/partners, peak 1 lakh+ new orders per minute.
• City-wise isolation: one city's issue must not bring down another city.

C.2 Estimation (back-of-the-envelope)

C.3 API design

C.4 Data model

C.5 High-level architecture

• Location path: Driver app -> LB -> WebSocket Gateway -> Location Service -> Redis Geo Index (cell set + TTL) -> Kafka.
• Ride path: Rider -> API Gateway -> Trip Service creates a row with status = requested in MySQL -> Dispatch takes the k-ring drivers from Redis.
• Dispatch ranks with the ETA Service + Map/Routing and sends the offer to the driver via the WS Gateway; on accept, a conditional UPDATE trips.
• Kafka events: the Flink surge calculator writes the multiplier into Redis surge; also Cassandra history, notification and payment workers.
• The 12.5 lakh location writes/s go not to a DB but to a city-wise sharded Redis geo index; trip and payment stay in strongly consistent SQL.

C.6 Main flows

Driver location update:

1. The driver app sends the GPS location every 4 sec over a WebSocket/gRPC stream.
2. The Location Service converts lat/lng into an H3 cell id.
3. If the cell changed, remove the driver from the old cell set and add them to the new one (Redis).
4. Latest location and status in the driver:{id} hash, TTL refreshed to 30 sec.
5. The event goes to Kafka: for the surge calculator, active trip tracking and history.
6. If the driver has an active trip, the WebSocket Gateway pushes the new location to the rider.

Ride request and driver matching:

1. After seeing the estimate, the rider sends POST /v1/rides with an Idempotency-Key.
2. The Trip Service creates the trip row with status = requested.
3. Dispatch gets the available drivers from the pickup H3 cell and the surrounding rings (k-ring).
4. It gets the actual road ETA of the top candidates from the ETA Service and ranks them (not straight-line distance).
5. The offer is pushed to the best driver with a 10-15 sec timeout; on reject/timeout, the next driver.
6. The driver accepts: UPDATE trips SET driver_id=?, status='assigned' WHERE id=? AND status='requested'.
7. At the same time the driver's status in Redis becomes busy (with a lock) so no other offer reaches them.
8. The rider gets the driver details and live ETA over the WebSocket.

Food order state machine:

1. The customer places the order and payment is authorized; status = placed.
2. The order goes to the restaurant app; on accept, status = accepted, with a prep time estimate.
3. Dispatch assigns the nearest partner slightly before the prep time ends so the food does not get cold.
4. The partner reaches the restaurant -> arrived, takes the food -> picked_up.
5. Live tracking reaches the customer over a WebSocket; the ETA is recomputed on every update.
6. On delivery status = delivered, with payment capture and partner payout through a Kafka worker.
7. Every transition is validated: for example you cannot go back from delivered to picked_up.

C.7 Deep dives

Problem: finding the nearest driver efficiently (among lakhs of drivers). Calculating distance over the whole table is slow. Use geo indexing: geohash or H3 hexagonal cells. Check only the drivers in the pickup cell + neighbour rings, then rank by road ETA.

Problem: 12 lakh/sec location writes. Do not write every update to a persistent DB. Use a city-wise sharded Redis geo index with a TTL; history goes in batches from Kafka to Cassandra/S3. Client-side batching, and a lower frequency when the driver is not moving.

Problem: one driver gets assigned to two riders (race condition). A short-lived distributed lock on the driver (Redis SET NX with TTL) plus a conditional update/optimistic locking (version) on the trip row. Only one transaction wins; the others get the next driver.

Problem: surge pricing in real time. Ride requests (demand) and available drivers (supply) stream on Kafka; Flink computes the ratio for every H3 cell in a 1-2 min window and puts the multiplier in Redis. Caps smooth out sudden jumps.

Problem: accurate ETA. A routing engine on a road graph (OpenStreetMap-like), live traffic speed per road segment, historical patterns and ML correction. For food, also model the restaurant prep time and parking time.

Problem: a flaky network: duplicate requests and lost updates. An Idempotency-Key on every write API; idempotent state machine transitions; on a WebSocket reconnect the client fetches the last known state; idempotent Kafka consumers.

C.8 Trade-offs

C.9 Interview tips

• Calculate and show the location update QPS: it makes clear that you need an in-memory geo index, not a DB.
• Explain the geohash/H3 concept and neighbour-cell search.
• Raise the double-assignment race condition yourself and solve it with locking/conditional updates.
• Describe the order state machine out loud and how invalid transitions are blocked.
• Mention city-wise sharding and isolation: geo systems naturally partition by city.