44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)
1
The interview prompt2
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 yourself13
Variations to practise14
Sources15
Code lab44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)
44.9 How does the trip state machine work?
3 min read+10 XP
A trip moves through fixed states: requested → matched → arriving → in_trip → completed, with cancelled possible early on.
- Events carry IDs: phones on bad networks resend "arrived" or "start trip". The trip service stores applied event IDs (unique), so a resend is a duplicate, not a second change. In the chapter's code, a repeated "matched" is ignored and an illegal jump from matched straight to in_trip is rejected.
- Server is the source of truth: apps show what the server confirms; if a phone and the server disagree, the phone re-syncs.
- Timeouts drive transitions too: no driver found in N minutes → cancelled; driver not moving toward pickup → reassign.
- Fare at completion: (base + per km + per minute) × the locked multiplier, with a minimum fare. In the chapter's code, an 8 km, 25-minute ride costs ₹174, ₹260 at ×1.5 surge, and a 1 km ride hits the ₹80 minimum (fare constants are assumptions).
- Payment follows Chapter 42's pattern: charge at the end with an idempotency key, or record cash.
Memory code: "Every event once, every move legal, every fare from the quote."