Art of Codeartofcode
Lesson 7 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.6 How are location updates handled?

3 min read+10 XP

Step 5: Deep dives (10 minutes)

As in Chapter 18, at higher volume:

  • Latest position only, in memory: a cell → drivers map (geohash, S2 or H3 cells) per city, plus driver → position, last-seen time and availability. In the chapter's code, a nearby query around the rider returns 38 of 2,000 drivers from neighbouring cells, includes the driver who just moved next to the rider, and skips one whose app went silent 100 seconds ago.
  • Move between cells only when the cell changes; most updates just overwrite a position.
  • Expire silent drivers after ~30 seconds.
  • History to a stream (Kafka), batched, for receipts, analytics and models.
  • Shard by city: a Bengaluru ride never needs Delhi's drivers.

Memory code: "Overwrite the position, move cells rarely, forget the silent."