Uber System Design: Real-Time Location, Geospatial Search, Dispatch, and Trip State
This is a reference design for an Uber-like ride-hailing platform, grounded in publicly documented Uber engineering concepts such as real-time marketplaces, routing, ETAs, and H3 geospatial indexing.
Keep Live Location Separate From Durable Trip State
Driver coordinates change frequently and are queried by geography. Trip state—requested, matched, accepted, started, completed—is lower-frequency business data that needs stronger durability and consistency.
Do not force both workloads into the same storage model simply because they belong to one product.
Use a Geospatial Index for Candidate Search
Searching every available driver for each ride request does not scale.
Uber developed H3, a hierarchical geospatial index that maps coordinates into hexagonal cells. A ride-hailing reference design can use cells to find nearby candidate drivers, expand to neighboring cells when supply is low, and aggregate marketplace demand/supply by area.
H3 narrows the candidate set; precise route/ETA scoring can happen afterward.
Matching Is More Than Nearest Distance
The closest driver by straight-line distance is not always the best match. A dispatch service can consider:
estimated pickup time
road/network conditions
driver availability
vehicle/service type
marketplace constraints
Uber's public engineering material explicitly describes routing and matching as core backend responsibilities.
Model Trip State Explicitly
Use a state machine rather than scattered booleans:
REQUESTED → MATCHED → ACCEPTED → ARRIVING → IN_TRIP → COMPLETED
↘ CANCELLED
Transitions should be idempotent because mobile clients and networks can retry requests.
Stream Updates Without Making Everything Durable Hot-Path Data
Rider and driver apps need near-real-time location/trip updates. WebSockets or another realtime channel can distribute those updates, while durable trip state remains in the authoritative backend.
Push notifications can cover offline/mobile-background cases.
Scale by Geography
Ride-hailing traffic is naturally local. Partitioning routing/location/dispatch work by city, region, or geospatial cell can reduce global coordination and contain hotspots.
Final Takeaway
An Uber-like platform separates high-frequency location data, geospatial candidate search, dispatch decisions, and durable trip state. Use geo indexing to narrow nearby candidates, routing/ETA logic to rank them, and an explicit state machine to keep the business workflow correct under retries and realtime updates.
References
BUILDING AN AI PRODUCT?
Talk to Lofingo about custom autonomous AI agents, enterprise workflow automation, and scalable software systems.
EXPLORE AI SERVICES →