Ride hailing app, like Uber
Matching riders and drivers: live locations in a geo index, dispatch, surge, trips and payments. A classic system design interview.
What is on this board
Parts
- Rider app Mobile app
- Driver app Mobile app
- API gateway API gateway
- Live updates WebSocket / realtime server
- Location service Service · Go
- Drivers nearby Geospatial index · Redis GEO
- Dispatch Service · Go
- Trips Service · Java
- Pricing Service
- Trips DB Relational DB · Postgres
- Trip events Event stream · Kafka
- Location history Data lake · S3
- Payments Payment provider · Stripe
- Routes and ETA Maps / geocoding API · Google Maps
- Notifications Email / SMS / push
How they connect
- Rider app → API gateway: requests a ride
- Driver app → Live updates: position
- Live updates → Location service: position
- Location service → Drivers nearby: latest position
- Location service → Trip events: position log
- API gateway → Dispatch: find a driver
- Dispatch → Drivers nearby: who is near?
- Dispatch → Routes and ETA: ETA
- Dispatch → Pricing: fare
- Dispatch → Live updates: offer to driver
- API gateway → Trips: trip
- Trips → Trips DB: SQL
- Trips → Trip events: trip changed
- Trip events → Location history: archive
- Trips → Payments: charge at the end
- Trips → Notifications: driver is here
Notes and decisions
- API gateway: Auth, rate limits, routing
- Live updates: Holds a connection per driver and rider
- Location service: Takes a position every 4 seconds per driver
- Drivers nearby: Only the latest position
- Dispatch: Offers a ride to the closest drivers, one at a time
- Trips: The state of a ride
- Pricing: Fare and surge per area
- Trips DB: Sharded by city
- Why not write every position to Postgres? Millions of writes a minute for data that is stale in 4 seconds. Keep the latest in Redis, the history in the stream.
- How do we stop two drivers getting the same ride? Lock the driver in dispatch with a short TTL.
- Follow-ups an interviewer asks: surge pricing, a city outage, a driver who goes offline mid-offer.
Inside dispatch
Parts
- Ride requested Domain event
- Find drivers in the area Process
- Anyone free? Decision
- Offer to the closest, for 15 seconds Process
- Accepted? Decision
- Lock the driver, create the trip Process
- Widen the area Process
- No drivers: tell the rider Start / end
- On the way Start / end
How they connect
- Anyone free? → Offer to the closest, for 15 seconds: yes
- Anyone free? → Widen the area: no
- Widen the area → No drivers: tell the rider: third try
- Accepted? → Lock the driver, create the trip: yes
- Accepted? → Find drivers in the area: no, next driver
More like this
News feed, like TwitterFan-out on write or on read? Timelines in a cache, the celebrity problem, and how a post reaches millions of followers.
News feed, like TwitterFan-out on write or on read? Timelines in a cache, the celebrity problem, and how a post reaches millions of followers.
URL shortener, like BitlyThe first system design interview question: key generation, heavy reads, a cache in front, and click analytics off the request path.
