Art of Codeartofcode
Lesson 6 of 15

44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)

1
The interview prompt
2
44.1 What do you ask first?
3
44.2 How big is this, really?
4
44.3 What are the doors?
5
44.4 What do we store?
6
44.5 What does the whole system look like?
7
44.6 How are location updates handled?
8
44.7 How does matching work?
9
44.8 How does surge pricing work?
10
44.9 How does the trip state machine work?
11
44.10 What would you say in the last five minutes?
12
Score yourself
13
Variations to practise
14
Sources
15
Code lab
44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)

44.5 What does the whole system look like?

3 min read+10 XP

Step 4: High-level design (10 minutes)

driver apps stream locations to a location service that updates an in-memory driver index and a location stream; the rider app talks to a trip service; the matcher queries the index, asks maps for ETAs and offers trips; pricing computes surge per cell.

Figure: the final design. Locations flow into memory; requests flow through quote, match, offer and trip states.

A ride, step by step:

  1. Drivers stream locations every 4 seconds over a WebSocket (Chapter 21). The location service validates them and updates the driver index (in memory, per city, by cell); it also appends them to a location stream.
  2. The rider asks for a quote: pricing combines distance, time and the pickup cell's surge multiplier (44.8). The quote is stored with an expiry.
  3. The rider confirms; the trip service creates the trip (state requested, idempotency key, Chapter 24).
  4. The matcher gets nearby available drivers from the index, ranks them by road ETA from the maps service, and offers the trip to the best one, with a timeout (44.7).
  5. The driver accepts; the matcher assigns atomically (only if the driver is still free); the trip becomes matched, and the rider sees the car coming.
  6. The trip moves through arriving → in_trip → completed via events from the driver app (44.9); the fare uses the quote's locked multiplier.

Interviewer pushback:

  • "The matcher for Bengaluru dies." → Matchers are stateless per city and replicated; requests are retried by another instance; the trip table shows which trips still need a driver.
  • "A driver's phone goes into a tunnel." → They stop appearing in the index after 30 seconds without updates (Chapter 18), so no new offers go to them; their current trip continues and catches up when they reconnect.

Memory code: "Quote, request, find by ETA, offer, assign once, track by states."

Offer: "The interesting parts are location updates, matching, surge pricing and the trip state machine. Which would you like?"