Ride Sharing diagram template
Match riders and drivers with a location service, geospatial index and trip state machine.
About this design
Ride sharing combines a hot stream of location updates with a low-volume, high-stakes trip lifecycle, and the design keeps them apart. Drivers send their position every few seconds to a location service that writes into an in-memory geospatial index, so a nearby search is a single radius query instead of a database scan. A matching service reads candidates from that index, scores them on distance and rating, and offers the trip to one driver at a time. Once accepted, the trip enters a state machine in a relational database where correctness matters more than speed, and payments are triggered only from that record. Notifications and live tracking flow back to the rider over a push channel. Discuss geohash versus quadtree, surge pricing as a separate service, and what to do when a driver app loses connectivity mid-trip.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Ride sharing"
direction LR
mobile "Driver app" -> service loc "Location service" -> cache redis "Geo index"
mobile "Rider app" -> gateway "API gateway" -> service match "Matching service"
match -> geo-index
match -> service trip "Trip service" -> db postgres "Trips DB"
trip -> external stripe "Payments"
trip -> queue kafka "Trip events" -> worker notify "Notifications"
