Design a Ride-Hailing Backend That Matches Riders With Nearby Drivers

Design the backend for an Uber-style ride-hailing service. Riders request a trip from a pickup point to a destination; the system finds a nearby available driver, offers the trip, and tracks the ride through to completion. In this round the interviewer is the hiring manager, who expects you to lead: clarify requirements, grow the architecture step by step, say what each component is for, weigh trade-offs, and propose improvements. Expect suggestions from the interviewer partway through, and fold them into your design without losing the thread. ```hint Separate the hot path Ask which data changes many times per minute and which changes only a few times per trip; the two rarely belong in the same store. ``` ```hint Find the race Picture two riders requesting at the same moment with a single driver nearby, and decide what in your design guarantees that only one of them gets that driver. ``` ### Constraints and Clarifications Assume this standard scope unless the interviewer narrows it: - Riders can see a fare estimate, request a ride, and watch the assigned driver approach in near real time. - Drivers go online or offline and, while online, periodically report their location. - A request is matched to a nearby available driver, who can accept or decline within a short window; a driver must never be committed to two trips at once. - A trip moves through clear states (requested, driver assigned, in progress, completed, or cancelled) and ends with payment, which can be delegated to an external payment provider. - Out of scope unless asked: shared rides, scheduled rides, driver onboarding and ratings. - No traffic figures are given: choose your own scale assumptions, state them, and size the system from them. ### Clarifying Questions - Should matching minimize straight-line distance, estimated time to pickup, or something broader such as the chance a driver accepts? - Is a request offered to one driver at a time, or can several drivers see the same request at once? - How stale can a driver's location be before matching quality suffers? - Is dynamic (surge) pricing in scope? - Is this one region at first, or several regions with data residency requirements? ### What a Strong Answer Covers - Requirements and scale assumptions stated up front and used to size the location pipeline - Core entities, APIs and a ride state machine - An efficient proximity search over moving drivers, with a justified geospatial index choice - A matching and dispatch flow that cannot double-assign a driver and handles declines, timeouts and cancellations - Real-time updates to riders and drivers, and behavior when services or devices fail - A candidate-led narrative that absorbs the interviewer's suggestions and names concrete improvements ### Follow-up Questions - A large event ends and a burst of requests appears in a few city blocks. What breaks first, and how do you adapt? - The matching service crashes mid-dispatch. How do you make sure no request is lost and no driver is left reserved? - How would you add surge pricing without slowing down the request path? - How would you extend matching to support shared rides?