Design a Ride-Hailing Platform: Driver Matching, Surge Pricing and Ride Acceptance

Design the core backend of a ride-hailing platform: a rider requests a trip from their location, the system finds a suitable nearby driver, the driver accepts, and the trip proceeds. The round mixes high-level and low-level design and concentrates on three areas: matching riders with drivers, surge pricing when demand outstrips supply, and the flow in which a driver receives a ride request and accepts or declines it. ### Constraints and Clarifications - Riders and drivers use mobile apps, and driver apps report their location periodically while online. - Payments, ratings, maps and routing can be treated as existing services you call; for example, a routing service returns travel-time estimates between two points. - Scale, the location update frequency and how long a driver has to respond are not given. Agree on them before sizing anything. ### Clarifying Questions - How many drivers are online at peak, and how many trip requests per second must the system handle? - How often does a driver's app send its location? - Should "nearest" mean straight-line distance or estimated arrival time on the road network? - How long does a driver have to respond to an offer, and may one request be offered to several drivers at once? - How fine-grained should surge areas be, how often should multipliers update, and is the price shown to the rider binding? - Which ride types are in scope: single riders only, or shared rides as well? ### Part 1 — Requirements, APIs and high-level architecture Define the requirements and a capacity estimate, the APIs for riders and drivers, and the main services, including how driver locations are ingested and stored. ```hint Location is the hot path Work out how many location updates per second the fleet generates, and let that number decide where and how current driver positions are kept. ``` #### What This Part Should Cover - Requirements and sizing driven by location-update volume - Rider and driver APIs, including the persistent channel used to push offers - Service boundaries with clear ownership of trip state, driver state and locations ### Part 2 — Ride matching Explain how the system finds candidate drivers for a request and picks one: the spatial index, the ranking, and how a driver is prevented from being matched to two riders at once. ```hint Nearby is not a scan Think about how to find candidates without comparing the request against every online driver, and about what can make a closer driver the worse choice. ``` #### What This Part Should Cover - Spatial indexing and candidate search - Ranking criteria beyond raw distance - Exclusive reservation of a driver while an offer is outstanding - The trade-off between matching each request immediately and batching requests ### Part 3 — Driver offer and acceptance Design the flow from sending a ride offer to a driver through acceptance, decline or timeout, including moving on to the next driver. Give the trip state machine and the classes or components that enforce it. ```hint Two accepts, one trip Picture a slow network delivering a driver's accept after the offer has already moved on to someone else, and decide what single check rejects it. ``` #### What This Part Should Cover - Trip and driver state machines with their legal transitions - Timeouts, declines and retries without losing or duplicating a trip - Idempotent handling of late or repeated messages from the apps - Delivering offers over unreliable mobile connections ### Part 4 — Surge pricing Design how surge multipliers are computed per area and applied to fares, and how the price quoted to a rider is honored. ```hint Measure both sides Decide which signals represent demand and supply in an area over a short window, and how to stop the multiplier from jumping between neighboring areas or from one minute to the next. ``` #### What This Part Should Cover - Demand and supply signals per area and time window - The computation pipeline and how fresh its output is - Smoothing, caps and stability - Price quotes that are honored when the trip is booked ### What a Strong Answer Covers - Sizing that identifies location updates as the dominant load - A geospatial design that scales by sharding and keeps current positions in memory - Strong guarantees exactly where they are needed (one driver per trip, one trip per driver) and cheaper consistency elsewhere - Clear state machines and failure handling suited to mobile networks - A surge model that is responsive yet stable and transparent to riders ### Follow-up Questions - How would you add shared rides, where one driver serves several riders on overlapping routes? - The location service for a whole region goes down. What do riders and drivers experience, and how does the system recover? - How would you detect and handle drivers who spoof their GPS position to game surge areas? - How would you test a change to the matching algorithm safely before rolling it out to every city?