Design a Ride-Hailing Platform With Real-Time Matching and Exactly-Once Charging

Design a ride-hailing service like Uber. Riders request trips, nearby available drivers are found and one is assigned, both sides follow the trip's status live, and the rider is charged when the trip ends. This round draws on designs such as ride sharing and payment processing, and the interviewer expects the design to hold up on payment correctness and failure recovery as well as on matching. ### Clarifying Questions - Which ride products are in scope: one rider per trip only, or also shared and scheduled rides? - What scale should the design target: peak trip requests per second, and how many online drivers sending location updates? - Does an external payment provider move the money, and does the design include driver payouts or only charging riders? - Is dynamic (surge) pricing in scope, and is the rider charged the quoted price or a price computed at the end of the trip? - What is the cancellation policy: when does cancelling cost the rider a fee? ### Part 1 — Requirements, data model and APIs State the functional and non-functional requirements, estimate peak load, define the core entities and the database design, list the API endpoints, and draw the system diagram. ```hint Let the trip drive the model Write the trip's life cycle as a state machine first; most entities, endpoints and later failure cases hang off its transitions. ``` #### What This Part Should Cover - Requirements that separate what must be strongly consistent (assignment, money) from what can be approximate (locations). - Peak throughput estimates for location updates, trip requests and state changes. - Entities, storage choices and endpoints consistent with the trip life cycle, and a diagram with clear responsibilities. ### Part 2 — Finding and assigning drivers Design the geospatial search for nearby available drivers and the assignment of exactly one driver to each trip. Explain how the system stays correct when many requests compete for the same drivers, including the role of distributed locks, and how reads and writes scale, including sharding. ```hint Two riders, one driver Two matching requests pick the same idle driver at the same moment. What single check guarantees that only one of them wins, even if a lock holder stalls? ``` #### What This Part Should Cover - The geospatial index, its update path, and how the search expands. - Assignment correctness under contention: distributed locks, their failure modes, and alternatives. - Sharding and scaling of location writes, trip writes and frequent reads. ### Part 3 — Charging exactly once Design the payment flow from trip request to completed charge so that no rider is charged twice and no completed trip goes uncharged, despite client retries, service crashes and payment-provider timeouts. Cover idempotent transactions, atomic writes, transaction logging, crash recovery and replay, the audit trail and reconciliation, and the workflow tooling or durable execution that drives the multi-step process. ```hint Assume everything is retried Assume every call is retried by someone: the rider app, your own workflow, or the provider's webhooks. Make each step safe to run twice. ``` #### What This Part Should Cover - Idempotency at each boundary, and atomic writes of state changes, ledger entries and events. - Handling unknown outcomes such as timeouts, and recovering after crashes through durable execution and replay. - Ledger design, audit trail and reconciliation against the payment provider. ### Part 4 — Cancellations and live updates Handle cancellation by the rider or the driver at every stage of the trip, including races with driver acceptance and with payment. Then choose how clients receive state changes: server-sent events (SSE), WebSockets or push notifications. ```hint Foreground and background differ Compare what a rider needs while the app is open with what it needs while the phone is locked; the transport can differ. ``` #### What This Part Should Cover - Cancellation as state-machine transitions that stay correct under races, with fee and payment-hold handling. - A transport choice per client and situation, with ordering, reconnection and recovery of missed updates. ### What a Strong Answer Covers - System-wide scaling and weak points: busy areas, shard failures, payment-provider outages, reconnect storms. - Clear consistency boundaries: strong for money and assignment, eventual for locations and read models. - Observability: the metrics and invariants that catch matching and payment problems early. - Trade-offs weighed explicitly rather than a list of components. ### Follow-up Questions - A capture request to the payment provider times out and you do not know whether the rider was charged. Walk through exactly what happens next. - The location store for a large city fails during the evening peak. What do riders and drivers experience, and how does the system recover? - How would you guarantee that a rider pays the quoted price when surge pricing changes while matching is in progress? - Reconciliation finds a charge at the provider with no matching ledger entry. What could have created it, and what should the system do?