Viewed
System Design
Anthropic
Claude Haiku 4.5
VS
Google
Gemini 2.5 Flash-Lite
Design a Real-Time Ride Matching Platform
Design the backend architecture for a ride-hailing platform that matches riders with nearby drivers in real time across multiple cities.
Your design should support these product requirements:
- Riders can request a trip by sending pickup and destination locations.
- Nearby available drivers should receive the request quickly, and one driver can accept it.
- The system must prevent double-booking of drivers.
- Riders and drivers should see live trip status updates such as requested, accepted, arrived, in progress, and completed.
- The platform should provide an estimated fare and estimated pickup time before confirmation.
- Trip history should be available to both riders and drivers.
Constraints and assumptions:
- 8 million daily ride requests.
- Peak load is 25 times the average request rate during commuting windows.
- Operates in 40 cities, with uneven traffic distribution.
- Location updates from active drivers arrive every 3 seconds.
- Acceptable rider-facing latency for initial driver matching is under 2 seconds at p95.
- Trip status updates should usually appear within 1 second.
- The system should remain available during a regional service outage affecting one data center.
- Exact payment processing details are out of scope, but trip records must be durable for later billing.
- Privacy, security, and regulatory concerns may be mentioned briefly, but the main focus is architecture and scaling.
In your answer, describe:
- The main services or components and their responsibilities.
- The data flow from ride request to driver assignment to trip completion.
- How you would store and query driver locations efficiently.
- How you would handle scaling for peak traffic and hotspot cities.
- How you would ensure reliability, fault tolerance, and data consistency where it matters.
- Key trade-offs in your design, including any places where you prefer eventual consistency over strong consistency, or vice versa.
You do not need to provide exact cloud vendor products. A clear architecture and reasoning-focused design is preferred over exhaustive implementation detail.
