Loading low-level design…

Design Uber - Low-Level Design | OneNoughtOne

00:00:00

Design Uber

Advanced

Design an object - oriented ride - hailing service(like Uber) that supports rider and driver registration, driver online / offline toggling with live location, ride requests with fare estimation, nearest - driver matching within a configurable radius, a full trip lifecycle(assigned → en route → arrived → in progress → completed), multi - tier pricing(base + per - km + per - minute by vehicle type), surge pricing, and a mutual rating system.

Drivers have vehicles of different types(Bike, Auto, Mini, Sedan, SUV, Premium).Driver matching uses the Strategy pattern — default is nearest by Haversine distance.Pricing also uses Strategy pattern — standard pricing with per - type rates, or surge pricing with a configurable multiplier.

Core Use Cases

Riders and drivers register with profile, vehicle (for drivers), and contact info

Driver go online/offline

Drivers toggle availability and share their live location

Request a ride

Rider specifies pickup, dropoff, and vehicle type; get fare estimate

Match driver

Find nearest available driver (by vehicle type) within a radius

Trip lifecycle

DRIVER_ASSIGNED → DRIVER_EN_ROUTE → ARRIVED → IN_PROGRESS → COMPLETED

Fare calculation

Base fare + per-km + per-minute, varies by vehicle type

Surge pricing

Apply a demand multiplier to the standard fare

Rating system

Mutual rating: rider rates driver and driver rates rider (1-5)

Trip cancellation

Either party can cancel before/during trip

Constraints

A driver can only be on one trip at a time
Only AVAILABLE drivers can be matched to ride requests
Driver must match the requested vehicle type
Matching searches within a configurable radius (default 5 km)
Ratings are clamped to [1, 5] and averaged cumulatively

Assumptions

In-memory storage (no database)
Single-threaded (concurrency is a follow-up)
Haversine distance for location calculations (no routing API)
Payment processing is out of scope (simulated)
Single city / region (no multi-region dispatch)

In Scope

Rider and Driver registration with Vehicle
Driver online/offline toggle with location
Ride request with fare estimation
Nearest driver matching (Strategy pattern)
Trip lifecycle (assign → en route → arrived → in progress → completed)
Pricing with base + per-km + per-minute by vehicle type
Surge pricing (Strategy pattern)
Mutual rating system
Trip cancellation

Out of Scope

Real payment gateway integration
Real-time GPS tracking / map rendering
Ride pooling / shared rides (UberPool)
Driver earnings and payouts
Multi-city / region dispatch
ETA calculation with traffic

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

00:00:00

Design Uber

Advanced

Core Use Cases

Riders and drivers register with profile, vehicle (for drivers), and contact info

Driver go online/offline

Drivers toggle availability and share their live location

Request a ride

Rider specifies pickup, dropoff, and vehicle type; get fare estimate

Match driver

Find nearest available driver (by vehicle type) within a radius

Trip lifecycle

DRIVER_ASSIGNED → DRIVER_EN_ROUTE → ARRIVED → IN_PROGRESS → COMPLETED

Fare calculation

Base fare + per-km + per-minute, varies by vehicle type

Surge pricing

Apply a demand multiplier to the standard fare

Rating system

Mutual rating: rider rates driver and driver rates rider (1-5)

Trip cancellation

Either party can cancel before/during trip

Constraints

A driver can only be on one trip at a time
Only AVAILABLE drivers can be matched to ride requests
Driver must match the requested vehicle type
Matching searches within a configurable radius (default 5 km)
Ratings are clamped to [1, 5] and averaged cumulatively

Assumptions

In-memory storage (no database)
Single-threaded (concurrency is a follow-up)
Haversine distance for location calculations (no routing API)
Payment processing is out of scope (simulated)
Single city / region (no multi-region dispatch)

In Scope

Rider and Driver registration with Vehicle
Driver online/offline toggle with location
Ride request with fare estimation
Nearest driver matching (Strategy pattern)
Trip lifecycle (assign → en route → arrived → in progress → completed)
Pricing with base + per-km + per-minute by vehicle type
Surge pricing (Strategy pattern)
Mutual rating system
Trip cancellation

Out of Scope

Real payment gateway integration
Real-time GPS tracking / map rendering
Ride pooling / shared rides (UberPool)
Driver earnings and payouts
Multi-city / region dispatch
ETA calculation with traffic

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design Uber

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design Uber

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design Uber

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you handle concurrent ride requests competing for the same driver?

2How would you implement ride pooling (UberPool)?

3How would you implement real-time driver location tracking?

4How would you add fare splitting among multiple riders?

5How would you implement dynamic surge pricing based on real demand?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions

Design Uber

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you handle concurrent ride requests competing for the same driver?

2How would you implement ride pooling (UberPool)?

3How would you implement real-time driver location tracking?

4How would you add fare splitting among multiple riders?

5How would you implement dynamic surge pricing based on real demand?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions