Practice: Design Ride Sharing System
Ride sharing platform with matching, trip management, and notifications.
Build this system yourself on the canvas below. Add components, connect them, and run traffic simulations to see where your design holds up and where it breaks.
Functional requirements
- Riders can request a ride by specifying pickup and drop-off locations.
- The system matches a rider to the nearest available driver within 30 seconds.
- Drivers receive ride requests with rider details and can accept or decline.
- Riders and drivers can track each other's real-time location on a map.
- Trip fare is calculated dynamically based on distance, time, and surge pricing.
- Riders and drivers receive push notifications at key trip milestones.
- Riders can rate drivers and drivers can rate riders after each completed trip.
- Riders can view their trip history, receipts, and re-request past routes.
- Drivers can toggle availability and view their earnings dashboard.
- The system supports scheduled rides booked up to 7 days in advance.
Non-functional requirements
- Availability: 99.99% uptime; matching service must tolerate zone-level failures.
- Latency: driver-match response under 3 seconds for 95% of requests; location updates ingested under 500 ms.
- Scalability: support 10 million concurrent trips and 5 million active drivers globally.
- Throughput: ingest 500,000 driver location updates per second at peak.
- Geo-distribution: region-local matching clusters to minimise cross-region latency.
- Consistency: trip state machine (requested → matched → en route → completed) must be strongly consistent.
- Durability: all trip records and payment events persisted with zero data loss.
- Performance: surge-price recalculation refreshed every 30 seconds per geohash zone.
- Security: driver background-check status verified before any match; rider PII encrypted at rest.
- Observability: per-city ETA accuracy, match rate, and cancellation rate surfaced in real-time dashboards.
