Design Uber / Ola Ride Dispatch & Trip Lifecycle
In a 45-minute LLD interview, this problem evaluates state machine design, swappable dispatch algorithms, dynamic fare calculation, and real-time observer notifications. Scope the design to: modeling riders and drivers, matching drivers via interchangeable strategies (NearestDriverStrategy, HighestRatedDriverStrategy), calculating fares with normal and surge strategies, enforcing a strict trip lifecycle (Requested → DriverAssigned → InProgress → Completed / Cancelled), and broadcasting status updates to observers. Geospatial indexing (H3/S2) and payment gateways can be highlighted as production extensions.
Problem statement & clarifying requirements
Design a ride-sharing dispatch service like Uber or Ola. The platform must match ride requests to drivers using swappable strategies (such as Nearest Driver or Highest-Rated Driver), calculate fares dynamically under normal and surge pricing, guide each ride through a strict Trip Lifecycle State Machine (Requested → DriverAssigned → InProgress → Completed / Cancelled), and broadcast live status updates to both rider and driver via an Observer event bus.
No. A trip can be cancelled while in Requested or DriverAssigned states, but cancellation is strictly forbidden once InProgress (the passenger is already onboard).
Driver matching follows the Strategy pattern: dispatchers can toggle between NearestDriverStrategy during normal hours and HighestRatedDriverStrategy for premium tiers or special events without altering trip logic.
Fare estimation uses a Strategy / Decorator: SurgeFareStrategy wraps NormalFareStrategy and applies a dynamic demand multiplier (e.g., 1.5x to 2.5x).
The Trip context acts as an Observer Subject: every state change publishes structured transition events to attached ITripObserver subscribers (push notifications, driver telemetry).
First, sketch the design yourself
Spend 5 minutes listing the classes, who owns whom, and which interface hides the part that changes.
- 1.
Avoid sprawling
switch(status)statements insideTripmethods; use the State pattern so each phase encapsulates its own allowed transitions and guard clauses. - 2.
Ensure driver availability invariants are maintained across all terminal states: whether a trip finishes via
completeTrip()or aborts viacancelTrip(), the assigned driver must be freed back to the active fleet. - 3.
Decouple pricing and matching algorithms behind clean pure virtual interfaces so new algorithms (e.g. pooled rides, batched dispatch) plug in seamlessly.
How to think through this problem (5-step walkthrough)
In a 45-minute LLD interview, this problem evaluates state machine design, swappable dispatch algorithms, dynamic fare calculation, and real-time observer notifications. Scope the design to: modeling riders and drivers, matching drivers via interchangeable strategies (NearestDriverStrategy, HighestRatedDriverStrategy), calculating fares with normal and surge strategies, enforcing a strict trip lifecycle (Requested → DriverAssigned → InProgress → Completed / Cancelled), and broadcasting status updates to observers. Geospatial indexing (H3/S2) and payment gateways can be highlighted as production extensions.
Not every noun in the prompt deserves its own class. Separate dumb data structs from stateful managers, and turn trivial nouns into fields or enums.
TripContext class tracking rider ID, pickup/drop coordinates, fare strategy, assigned driver, attached observers, and delegating lifecycle actions to the active ITripState.
ITripStatePolymorphic State contract (RequestedState, DriverAssignedState, InProgressState, CompletedState, CancelledState) defining allowed lifecycle transitions and action guards.
IDriverMatchingStrategyStrategy contract (NearestDriverStrategy, HighestRatedDriverStrategy) selecting the most suitable candidate from active available drivers.
IFareStrategyStrategy contract calculating trip fares based on distance, duration, and demand surges (NormalFareStrategy, SurgeFareStrategy).
ITripObserverObserver interface broadcasting lifecycle status changes (onTripEvent(tripId, event, msg)) to rider and driver push notification channels.
DistanceKilometers / SurgeMultiplierTrap noun — DistanceKilometers and SurgeMultiplier are simple floating-point scalars (double), not separate class hierarchies. Making them classes creates unnecessary object wrapping boilerplate with zero domain behavior.
A naive implementation models the trip lifecycle with a mutable enum (TripStatus) and sprawls switch(status) statements across every method in Trip. Guard logic like "cannot cancel when passenger is onboard" gets duplicated or forgotten. Adding new states (like DriverArrived or Disputed) requires editing every single method in Trip, directly violating the Open-Closed Principle and risking invalid state transitions.
Scattered conditionals allow illegal actions, such as completing a trip before assigning a driver or cancelling while in transit.
Hardcoding dispatch logic in the trip context prevents switching dispatch algorithms during peak demand or premium tiers.
Fixed fare calculation logic cannot adjust dynamically to weather surges, holiday pricing, or promotional discounts.
Calling rider SMS and driver notification services directly from trip transition methods entangles domain logic with external communication protocols.
- ✓
In-progress non-cancellability: A trip in
InProgressStatecannot be cancelled under any circumstances (cancelTrip()returnsfalse), protecting driver and passenger safety once transit begins. - ✓
Driver availability conservation: Whenever a trip reaches a terminal state (
CompletedStateorCancelledState), the assigned driver's availability flag must be released (isAvailable = true) so the driver rejoins the dispatchable fleet. - ✓
Notification atomicity: Every state transition executes through a central
transitionTo(newState, message)helper that atomically updates the state pointer and broadcasts the event to all attachedITripObserverinstances.
Entities & design patterns used
Unlock Full UML Diagram & C++23 Solution
The complete UML diagram, production-ready C++23 code, follow-up extensions, and design pitfall analysis are part of Brute2Best Pro. All 7 foundation chapters are 100% free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.