Art of Codeartofcode
Lesson 5 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.4 What do we store?

3 min read+10 XP
driver_index (in memory, per city) cell → drivers; driver → (lat, lng, last_seen, available) location log (stream: Kafka) driver_id, lat, lng, ts → analytics, ETA models, disputes quotes quote_id, pickup, drop, product, price, surge, expires_at trips (SQL, sharded by city) trip_id, rider, driver, state, quote_id, fare, timestamps trip_events trip_id, event_id (unique), type, ts (idempotent transitions) drivers profile, vehicle, status; current trip (for atomic assignment) surge (in memory, per city) cell → multiplier, updated every minute

Interviewer pushback:

  • "Why keep the location log at all if the index only needs the latest point?" → For trip receipts (actual route and distance), safety investigations, fraud checks and training ETA models. It's written asynchronously in batches (Chapter 22).

Memory code: "Latest position in memory, history in a stream, trips in a database."