Design a ride-hailing platform like Uber
UberSoftware Engineer · OnsiteLast updated
This question evaluates a candidate's competency in large-scale system design, covering distributed systems architecture, data modeling, real-time location streaming, matching algorithms, scalability, fault tolerance, and secure payment handling.
You are asked to design a large-scale ride-hailing platform similar to Uber.
Requirements
Functional requirements
- Riders can:
- Sign up, log in, and manage their profile.
- Request a ride from a pickup location to a destination.
- See nearby available drivers and estimated time of arrival (ETA).
- See an estimated fare before confirming the ride.
- Track the driver in real time once a ride is accepted.
- Pay via stored payment methods (e.g., credit card).
- Rate and review drivers after the ride.
- Drivers can:
- Sign up, go through onboarding, and register their vehicle.
- Go online/offline to indicate availability.
- Receive ride requests and accept/decline them.
- Navigate to the rider and then to the destination.
- The system should:
- Automatically match riders with nearby available drivers.
- Support surge pricing based on demand and supply in a geographic area.
- Store trip history (routes, prices, timestamps) for both riders and drivers.
- Send real-time notifications (push/SMS) about ride status updates.
Non-functional requirements
- High availability: Service should remain usable even if individual components fail.
- Low latency:
- Rider should see ETA and match results quickly (e.g., within a few hundred ms).
- Location updates should appear near real time.
- Scalability:
- Support millions of daily active users in multiple cities/regions.
- Reliability and consistency:
- Payments and trip records must not be lost or double charged.
- Some data (e.g., live location) can be eventually consistent.
- Security and privacy:
- Protect user data and payment information.
Task
Design the backend system for this platform. In your answer, cover:
- High-level architecture:
- Main services/components and how they interact (e.g., client apps, API gateway, core services).
- Data model and storage:
- Key entities (users, drivers, vehicles, trips, locations, payments) and a rough schema.
- Choice of databases (SQL / NoSQL / in-memory) and what to store where.
- Ride request and matching flow:
- How a rider request flows through the system.
- How to find and choose a nearby driver efficiently.
- Real-time location tracking:
- How drivers send location updates.
- How the system stores/serves this for ETAs and maps.
- Scalability and partitioning:
- How to scale by city/region or other keys.
- How to handle hotspots during rush hour.
- Reliability and fault tolerance:
- How to handle failures of individual services or data centers.
- How to ensure payments and trip records are durable.
- Additional considerations (briefly):
- Surge pricing approach.
- Monitoring, logging, and key metrics you would track.
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.