How would you design a ride-sharing app like Uber?
Why Interviewers Ask This
Mid-level System Design roles require deep understanding of this topic. Interviewers ask this to separate candidates who truly understand the mechanics from those who only know surface-level concepts.
Answer
Designing Uber-like ride sharing involves real-time location tracking, matching, and pricing. Core flows: driver shares location → rider requests ride → match driver to rider → ride in progress → payment. Location service: drivers send GPS updates every 4-5 seconds. 500K active drivers = 100K-125K location updates/second. Use Cassandra (time-series location: driver_id, timestamp, lat, lng) or Redis geospatial (GEOADD command stores driver positions, GEORADIUS queries nearby drivers in O(n+log n)). Matching service: when rider requests, find available drivers within radius, compute ETA for each, rank by ETA, offer ride to best candidate. Use geospatial indexes (S2 geometry library). Maps service: use third-party for routing/ETA (Google Maps Platform) or build own (HERE, OpenStreetMap + OSRM). ETA calculation crucial for matching and pricing. Surge pricing: real-time supply/demand ratio per geographic cell. Increase price multiplier when demand > supply × threshold. Trip service: state machine: REQUESTED → ACCEPTED → PICKUP → IN_PROGRESS → COMPLETED. Stored in PostgreSQL (ACID transactions for state transitions). Payment service: third-party (Stripe/Braintree). Payment authorized on match, captured on trip completion. Notification service: push notifications for driver-to-rider communication. WebSockets: maintain persistent connections with drivers for real-time location updates and ride assignments. Scale: separate services for location, matching, trips, payments, notifications.
Pro Tip
Before answering, structure your response: one-line definition → real-world analogy → concrete example from a project. This makes even complex System Design answers easy to follow.