Handbooks / System Design Case Studies / Chapter 13

Design a Ride-Hailing App like Uber

12 pages · ~18 min✓ Reviewed

Builds on Design a Food Delivery App like Zomato. Next up: Design a Ticket Booking System like BookMyShow.

System Design Case StudiesPage 1

Problem, Scope and Requirements (Ride-Hailing App)

1. Scope

Request ride: rider picks pickup and dropoff
Match nearby driver: find and offer to the best one
Live tracking: rider sees the driver on a map
Trip lifecycle: requested, assigned, in progress, completed
Fare and payment: estimate up front, charge at the end

Out: ride pooling (shared rides)
Out: scheduled rides (book for later)
Out: driver onboarding (documents, background checks)

2. Functional Requirements

Requestwith fare estimate
Offernearest driver
Accept / declinedriver decides
Tracklive trip tracking
Pay and rateafter the trip

System Design Case StudiesPage 2

High-Level Architecture (Ride-Hailing App)

1. Edge and Core Services

API gateway: REST for rides, fares and payments; handles auth and rate limits
WebSocket gateway: live channels for drivers and riders
~1.5M persistent connections ÷ ~50K per node ≈ 30+ gateway nodes
Each service owns its own datastore; no service reads another's tables

Service	Job	Owns

System Design Case StudiesPage 3

Location Updates and Tracking Service (Ride-Hailing App)

1. Responsibility and Design

Ingest driver GPS pings every 4s (every 1s during a trip)
Keep the latest position per driver
During a trip, fan out each ping to the rider
Load: 1.5M drivers ÷ 4s ≈ 375K writes/s, ~100 B each ≈ 37 MB/s

Driver appGPS ping
WebSocket gatewaypersistent conn
Location servicevalidate
Redislatest, TTL 30s
Kafkaappend history

System Design Case StudiesPage 4

Geospatial Indexing: Geohash, Quadtree, H3 (Ride-Hailing App)

1. Geohash

Geohash interleaves lat/lng bits into a base32 string
Shared prefix = nearby cells
Precision 6 ≈ 1.2 km × 0.6 km cell
Precision 7 ≈ 150 m cell
Stored as a Redis sorted set or a prefix index

Neighbors across a cell edge can have totally different prefixes
A prefix match alone misses drivers just over the edge
Cell shapes distort near the poles

System Design Case StudiesPage 5

Driver Matching and Dispatch (Ride-Hailing App)

1. Job and Candidate Search

Pick the best available driver for a ride request
Match SLA: 2s p99 to produce an offer
5–15s end to end, including the driver accept

Query the H3 res-8 cell plus k-ring(1–2) for status=AVAILABLE
Drop candidates whose driver:{id} is missing or whose ts is stale
Rank by ETA to pickup, not straight-line distance

System Design Case StudiesPage 6

Trip State Machine (Ride-Hailing App)

1. States

Happy path

1REQUESTEDrider asks
2MATCHINGdispatch runs
3DRIVER_ASSIGNEDdriver accepted
4DRIVER_ARRIVEDat pickup
5IN_PROGRESStrip started
6COMPLETEDfare computed
7PAIDcharge captured

CANCELLED: rider or driver cancels, from any state before IN_PROGRESS
NO_DRIVER_FOUND: MATCHING exhausted its attempts and radius expansion
Terminal states: PAID, CANCELLED, NO_DRIVER_FOUND

2. Guarded Transitions

System Design Case StudiesPage 7

ETA and Routing Service (Ride-Hailing App)

1. What the Service Does

Target: p99 < 100 ms per estimate
Load: ~100K estimates/s at peak
Callers: Matching, Trip and Pricing services

Estimate	Used for	Caller
Pickup ETA	ranking drivers	Matching
Trip ETA

System Design Case StudiesPage 8

Surge Pricing (Ride-Hailing App)

1. What Surge Does

Goal: balance supply and demand per H3 cell
multiplier = f(open ride requests ÷ available drivers)
Recomputed every 1–2 minutes, not per request
Higher price pulls drivers in and trims marginal demand

2. Pipeline and Example

Kafkatrip requests + driver availability
Flink jobcount per H3 res-8 cell, sliding 5-min window
Redissurge:{cell} = multiplier

System Design Case StudiesPage 9

Payments and Fare Settlement (Ride-Hailing App)

1. Responsibility and Flow

Authorize on request, charge on trip end, pay out drivers, handle refunds and tips
Load: ~230 charges/s average (20M trips/day), 700/s peak
Hard rule: never charge twice, so payment is strongly consistent

Life of a fare

1Pre-authorizehold estimate + 20% at request
2COMPLETEDfinal = base + per-km + per-min × surge
3Capturecharge the final fare on the held card
4Ledger entryone DB transaction
5Driver payoutweekly batch

2. Idempotency

System Design Case StudiesPage 10

Handling Driver and Rider Disconnects (Ride-Hailing App)

1. Detecting a Dead Connection

Heartbeat: WebSocket ping every 5s in both directions
15s with no heartbeat → connection marked suspect
30s with no location → driver:{id} expires (TTL 30s)
Suspect is a flag only: nothing is removed from the geo index yet

Silence timeline

10slast heartbeat
25sheartbeat missed
315sconnection suspect
430sdriver:{id} TTL expires
5~30slistener ZREMs from GEO set

System Design Case StudiesPage 11

Scaling, Failure Handling, Trade-offs and Interview Questions (Ride-Hailing App)

1. Scaling and Failure Handling

Layer	Sharded by	Why
Redis geo index	`city` or H3 parent cell	Hot cities get dedicated shards
Trips (SQL)	`trip_id`	Even spread, one trip = one shard
Kafka topics	`driver_id` or cell	Per-driver ordering kept

System Design Case StudiesPage 12

Check yourself

Two drivers are 50 m apart but sit on opposite sides of a geohash cell border. A rider's pickup is in cell A, and the service queries only cell A. Driver 2 is in cell B and is closer than anyone else. What happens, and what is the fix?

Driver 2 is missed, so the rider is matched to a farther driver or to nobody.
Geohash prefixes only guarantee that a shared prefix means close. Close does not guarantee a shared prefix.
Fix: query the pickup cell plus its 8 neighbors. With H3, query the k-ring (k=1 or 2).
Then rank by ETA, not straight-line distance.

Spot the bug: two ride requests run at the same moment. Each one reads driver D's status from Redis, sees AVAILABLE, and then writes OFFERED. What goes wrong, and how do you fix it?

Quantity	Estimate	How
Riders	20M	registered
Drivers	5M	registered
Online drivers	1.5M	concurrent
Trips	20M/day	≈ 230/s avg, 700/s peak
Location writes	375K/s	1.5M ÷ 4s
Location ingest	37 MB/s	375K × ~100 B

Requirement	Target	Consistency
Match latency	p99 < 2s from request	n/a
Location freshness	< 5s old	eventual
Trip flow availability	99.99% (≈ 52 min down/year)	strong
Trip and payment	no double charge, no double assignment	strong

Location	latest driver position	Redis geo index
Matching/Dispatch	pick driver, send offer	Redis offer state
Trip	trip lifecycle	sharded SQL
Pricing	fare estimate, surge	Redis `surge:{cell}`
ETA/Maps	routing, pickup ETA	road graph cache
Payment	authorize, capture, ledger	sharded SQL
Notification	push, SMS	delivery log

Topic	Producer	Consumers
`location.updates`	Location	analytics, S3 archive
`trip.events`	Trip	surge calculation, notifications, analytics
`payment.events`	Payment	fraud, analytics

Store	Key / topic	Holds	Retention
Redis	`driver:{id}`	`{lat, lng, heading, speed, ts, status}`	TTL 30s
Kafka	`location.updates`	history, partitioned by `driver_id`	days
S3	trip trace	full path per trip, ~3 TB/day raw	90 days

Signal	Target / handling
Redis shard lost	state rebuilt from the next ping, within 4s
Ingest latency	p99 < 100 ms
Location staleness	p99 < 5s (freshness NFR)
Dropped-update rate	< 0.1% of pings
Active connections	~1.5M WebSockets, ~50K per node

	Geohash	Quadtree	H3
Cell shape	rectangle	adaptive square	hexagon
Cell size	fixed per precision	splits at ~100 drivers	16 resolutions
Neighbors	8, prefixes differ	walk the pointers	6, equidistant
Sharding at 375K writes/s	easy by prefix	hard	easy by cell id

Item	Detail
`dispatch:{trip_id}`	offer log: driver, outcome, attempt count
`POST /rides`	rider requests a ride, starts matching
`POST /offers/{id}/accept`	driver accepts; claim must still be held

Metric	Target / note
Match rate	rides matched ÷ rides requested
Time-to-match	p50 and p99, p99 under 2s to first offer
Offer acceptance rate	~60–70%
Cancel-after-match rate	watch for bad ETAs or far drivers

Store	Shape	Notes
`trips`	`id, rider_id, driver_id, state, version, pickup, dropoff, fare_estimate, requested_at, started_at, ended_at`	sharded by trip_id
`trip_events`	one row per transition	append-only, for audit and replay

API	Purpose
`POST /trips`	create trip in REQUESTED
`POST /trips/{id}/start`	DRIVER_ARRIVED → IN_PROGRESS
`POST /trips/{id}/end`	IN_PROGRESS → COMPLETED
`POST /trips/{id}/cancel`	rider or driver exit to CANCELLED

Algorithm	Idea	Verdict
Dijkstra	expand outward from the origin	too slow for 100 ms
A* + partitions	heuristic plus precomputed regions	fast, flexible
Contraction hierarchies	precomputed shortcuts, query up then down	fastest queries

Step	Cell value
Open requests (5-min window)	40
Available drivers	10
Ratio	40 ÷ 10 = 4
Multiplier after cap	min(4, 2.5) = 2.5×

Situation	Behaviour
Multiplier stale or missing	default to 1.0×, never block rides
Runaway surge	hard cap per region
Disaster or public event	emergency override by ops

Table	Columns	Notes
`payments`	id, trip_id, amount, currency, status, psp_ref	`trip_id` UNIQUE
status	AUTHORIZED, CAPTURED, FAILED, REFUNDED	one status per payment
`ledger`	rider debit, driver credit, platform fee	double-entry rows

destination	eta_s	distance_m
0	240	1800
1	420	3100

Metric	Target
Auth success rate	> 98%
Capture latency	tracked (p99)
Reconciliation mismatches	0
Refund rate	tracked

Driver state	On disconnect	Outcome
AVAILABLE	Listener removes them from the geo index; matching skips a missing or stale `driver:{id}`	No new offers
OFFERED	Offer hits its 10–15s timeout, then goes to the next driver	Rider keeps matching
IN_PROGRESS	Trip stays alive, never auto-cancelled	Trip continues

Choice	Option A	Option B
Consistency	Strong: trips, payments	Eventual: location
Matching	Greedy: lowest latency	Batched (2s window): global optimum
Delivery	Polling: simple, wasteful	WebSocket: live; push: offers when app is closed
Geo index	Geohash: simple, edge gotchas	H3: uniform 6 neighbors, more tooling

Design a Ride-Hailing App like Uber

1. Scope

2. Functional Requirements

1. Edge and Core Services

1. Responsibility and Design

1. Geohash

1. Job and Candidate Search

1. States

2. Guarded Transitions

1. What the Service Does

1. What Surge Does

2. Pipeline and Example

1. Responsibility and Flow

2. Idempotency

1. Detecting a Dead Connection

1. Scaling and Failure Handling

3. Scale Estimate

4. Non-Functional Requirements

2. Where Data Lives

3. Kafka Event Backbone

4. Request Flow

2. Data Model

3. API and Validation

4. Failure and Metrics

2. Quadtree vs H3 vs Geohash

3. Choice for the Live Driver Index

2. Offer Flow

3. Atomic Claim

4. Data, API and Metrics

3. Data Model and APIs

4. Failures and Metrics

2. Road Graph and Routing

3. Matching and Live Traffic

4. API, Fallback and Metrics

3. Price Lock

4. Failure and Metrics

3. Data Model

4. Failures and Metrics

2. What Happens in Each Trip State

3. Reconnect and Offline Trips

4. Failure and Metrics

2. Key Trade-offs

3. Interview Answers

4. Cheatsheet