LLD8 min read
Ride Hailing (LLD slice)
Object model for booking a ride — Rider, Driver, Trip, MatchingStrategy, FareCalculator.
llddesign
Intro
The LLD piece of an Uber-like system: how do we model rider, driver, trip and matching such that adding 'Pool', 'Premium' or 'Auto' is a strategy swap, not a rewrite? We focus only on the booking-time object model — the dispatch infrastructure lives in the HLD article.
Functional
- Rider requests a ride from A → B with a category.
- System picks a nearby driver based on a strategy.
- Trip lifecycle: REQUESTED → ASSIGNED → STARTED → COMPLETED / CANCELLED.
- Fare = base + per-km + per-minute + surge multiplier.
Non-functional
- Strategy must accept different surge models without trip code changes.
- Trip events appended, never mutated.
Components
Rider, Driver
Profile + current location/state.
Trip
Aggregate root. Append-only state log.
MatchingStrategy
Nearest, Pool, Premium.
FareCalculator
Strategy with optional surge multiplier.
DriverIndex
Spatial index (Quadtree / S2) for k-NN driver lookup.
Trade-offs
Trip state machine inside Trip vs. as a service
Pros
- Inside Trip → invariants colocated with data.
- As service → easier to evolve transitions independently.
Cons
- Inside Trip can grow monolithic; as service can scatter ownership.