Design a ride-hailing backend

01Define the ride and the guarantee

Design a ride-hailing service for one operating region. A rider requests a pickup, nearby drivers receive offers, one driver accepts, and both participants track the trip through completion. Exclude pooling, surge-price calculation, route computation and a full payment ledger from the first answer. An external routing service can supply estimated pickup times; that does not require designing the road graph here.

Use ride R501, rider Maya and driver D17 throughout. The essential guarantees are that R501 has at most one winning driver and D17 has at most one active ride. Nearby-map results are approximate: a driver may move or accept another request before Maya acts. Only a committed acceptance creates an assignment.

Assume latest positions older than ten seconds are excluded from discovery, first offers arrive within two seconds for 95% of admitted requests with eligible nearby supply, and an accepted assignment commits within one second at the 95th percentile, excluding human decision time. These are negotiated targets. When the database cannot safely decide who owns a ride, pause assignment rather than report success from competing regional writers. GPS availability and durable trip availability remain separate concerns.

Ask whether matching must choose the globally best driver or a suitable nearby driver, whether assignments cross operating regions, and whether billing belongs in scope. Choose suitable regional matching here; confirm the assignment and location targets below before expanding the architecture.

02Functional requirements

1. Request and discover. Create a ride request, find suitable nearby available drivers and send bounded, expiring offers.

2. Accept and manage a trip. Allow one offered driver to accept, then support authorized start, completion and cancellation transitions.

3. Track participants. Publish recent driver positions and deliver active-trip updates to the rider and driver.

4. Recover status. Let either participant retrieve authoritative trip state after a lost response or disconnected socket without creating another ride or assignment.

03Non-functional requirements

These are illustrative interview assumptions, not product facts or measured benchmarks. Confirm them before choosing components, then validate the completed design under the stated workload. Here p95 means the 95th-percentile latency: 95% of measured requests take no longer than that value. Report errors and rejected work alongside latency; a fast failure is not a successful outcome.

1. Workload. Plan for 500,000 concurrently online drivers updating every three seconds, about 166,667 position updates/s, and one million rides/day. Size localized surges separately from daily averages.

2. Response time. Target a first offer within two seconds for 95% of admitted requests with eligible nearby supply. Target acceptance commit within one second p95, excluding driver decision time. Track no-supply outcomes separately rather than treating them as successful offers.

3. Position freshness. Exclude positions older than ten seconds from discovery. Matching remains approximate because drivers move and spatial indexing may lag.

4. Assignment correctness. Each ride has at most one winning driver and each driver at most one active ride. Cancellation and acceptance must make one consistent decision about both records.

5. Durability and availability. Require acknowledged assignments to survive one database-node failure using synchronous durable replication and safe failover. Pause assignment when current write authority cannot be established; a location outage must not erase an existing trip.

6. Access control. Authenticate drivers and riders, restrict precise tracking to current trip participants and prevent old sessions from overwriting new location updates.

04Follow one ride before adding services

Start with one regional application, a relational database and a connection gateway that sends messages to phones. The database stores rides, driver availability, offers and latest positions. Maya creates R501 with a request key. The application selects nearby available candidates, asks a routing service for a few pickup estimates, and sends a small batch of expiring offers.

D17 accepts offer O81. The application runs a short transaction that checks the offer, the ride and the driver together. It records assignment A77, marks both sides assigned, stores the successful reply for retries and commits notification work. After commit, the gateway informs Maya and D17. If the socket fails, the assignment still exists and either phone can retrieve it.

The trip then moves through assigned, in-progress and completed states, with cancellation allowed according to the agreed policy. Only authorized participants may change those states. Completion releases the driver through the same authority that assigned them. A location heartbeat cannot independently mark an assigned driver available.

This baseline already supports the whole user flow. More services later isolate high-volume location traffic and delivery work; they do not supply correctness that was absent from the first version.

05Size locations, rides and subscribers separately

Assume 500,000 drivers are concurrently online at peak and each sends a location every three seconds. That is about 166,667 updates per second. At a compact 40-byte payload, incoming coordinates alone use roughly 6.67 MB/s before network framing, authentication and replication. Daily active drivers are not automatically concurrent drivers, so state that assumption explicitly.

If five viewers subscribe to each driver, there are 2.5 million subscriptions and about 33.3 MB/s of raw outbound coordinate payload at the same update frequency. A million rides per day averages only 11.6 ride starts per second. The low average ride rate does not remove local station surges or justify storing every coordinate in the assignment database.

At 128 bytes per stored sample, retaining every three-second update from 500,000 drivers creates roughly 1.84 TB per day before replicas. Keeping only the latest record uses about 64 MB of raw records, although spatial indexes, connection maps and runtime overhead add substantial memory.

Measure peak updates, candidate counts, routing-call cost, first-offer delay and assignment transaction time separately. A slow routing dependency can dominate matching even while the database is lightly loaded. Bound candidate batches and timeouts instead of requesting precise routes for every driver in the city.

06Separate position, availability and trip state

Interfaces

Recover the running trip after reconnect

GET /rides/R501

Assignment result in the worked example

ride:       R501
driver:     D17
assignment: A77
state:      assigned

Stored records

Authentication determines the rider or driver; a submitted driver ID is not permission. Reusing a ride-creation key with another pickup must fail rather than silently return an unrelated trip. Retain replay results for a documented retry interval and expose status recovery afterward.

Index rides by rider and driver so reconnect does not require searching all trips. Store assignment A77 and an outbox event in the same transaction. The outbox is durable delivery work; a worker can retry notifying participants without making the assignment again. Connection records merely identify a current socket and may expire independently of the trip.

07Make acceptance atomic on both sides

All competing accepts for a driver and ride must reach records that can commit together in one regional database transaction. In a consistent lock order, lock the driver, the ride and the offer. Recheck a saved operation result after waiting for locks: a concurrent identical request may already have committed A77. Returning that result is correct; rejecting the retry because D17 is now busy is misleading.

For a new operation, perform these steps within the acceptance transaction:

1. Verify that O81 targets the authenticated driver, is active and has not expired. Check the authoritative database clock after acquiring locks, because the transaction may have waited past the deadline.

2. Require D17 to be available and R501 to remain offering with no assigned driver.

3. Insert the assignment, update both rows, mark the offer accepted and store replay and outbox records in one commit.

Unique active-driver and active-ride constraints provide additional protection.

If D17 also accepts R502, that transaction waits for D17 and then sees the assignment to R501. It cannot change R502. If D18 concurrently accepts R501, the ride check rejects that competing driver and leaves D18 available. Protecting only one side misses the other race.

Keep transactions short and handle bounded deadlock or serialization retries. Never hold database locks while waiting for a person to accept an offer or while calling a routing service.

08Scale approximate location discovery

When coordinate writes burden the assignment database, move latest positions to a partitioned position service. A spatial index maps cells to driver IDs. Every valid update changes the latest point; cell membership needs changing when the driver crosses a boundary, not for every small movement inside the same cell. Fixed or hierarchical cells are adequate before considering a custom adaptive tree.

Updates carry a server-issued session generation and an increasing sequence. Reject older generations and sequence numbers so delayed packets cannot overwrite a newer position. A restarted app gets a new authenticated generation before restarting its sequence numbers. Validate coordinates and observation age, while acknowledging that a phone can still report noisy or dishonest GPS.

The matcher covers the pickup area, retrieves candidate IDs, reads recent points and checks driver availability. It then evaluates a bounded shortlist using pickup suitability and estimated arrival time. A candidate is not a reservation; acceptance still uses the durable transaction.

A stale index can miss a driver who just entered the area. Freshly reading returned positions removes bad candidates but cannot discover an omitted arrival. Define and monitor indexing delay. Expanding the search area is justified only with credible bounds on movement, delay and measurement error; otherwise state that discovery may miss recently arrived drivers.

09Bound offers and preserve regional ownership

A matcher can process ride requests from durable pending-work records once bursts exceed synchronous capacity. It reads current ride state before each offer batch, so canceled or assigned rides do not keep generating offers. Offer a few suitable drivers at a time, set deadlines, and move to another batch after all valid offers fail or expire. Unlimited broadcasting wastes routing calls and interrupts drivers who cannot all win.

Partition independent operating regions to distribute workload, keeping their ride and driver records together. Location cells and transaction ownership serve different purposes. Moving ten meters across a cell edge should not move the driver’s assignment records to another database owner. An active trip can retain its original authority through completion even when it crosses a regional boundary.

If idle drivers must transfer between regions, stop creating new offers, drain or invalidate old offers, and transfer the authoritative record before enabling the new owner. A monotonically increasing ownership version lets the storage path reject commands from the previous owner. Routing alone cannot stop a paused old process from resuming.

Cross-region assignment is therefore an advanced extension, not a free consequence of drawing multiple matchers. It requires a reservation/transfer protocol or a distributed transaction that preserves both sides of the assignment guarantee.

10Recover trips independently of phone connections

After assignment, authorize Maya and D17 to subscribe to R501. A connection directory maps each participant to a gateway, and each location message includes its session and sequence. The gateway can discard intermediate points for a slow phone and retain only the newest observation. Showing the latest position is usually more useful than replaying a minute of obsolete dots.

Trip lifecycle events are different. Assigned, started, canceled and completed transitions must remain recoverable from durable trip state and the outbox. Events carry trip ID and version. The client ignores older versions and fetches current status when a gap or reconnect occurs. A push notification may wake an app, but it is not authoritative proof that a ride remains assigned.

Cancellation races use the same ride and driver authority. If cancellation commits before acceptance, the offer cannot win. If assignment commits first, cancellation follows the assigned-trip policy and clears the ride and driver assignment together when permitted. A temporary socket loss does neither.

Discovery may show coarsened positions to protect drivers. Precise active-trip coordinates require current participant authorization and bounded retention. A new socket must reauthenticate; possession of an old trip ID alone is insufficient to subscribe.

11Trace the failures that change the answer

Use synchronous durable database replication and safe failover to preserve acknowledged assignments across one database-node failure. An asynchronous replica may lose recent commits during promotion; counting three servers is not a durability argument. Stop unsafe writes when the database cannot establish which primary may write rather than create two successful assignments for one driver.

During a station surge, bound waiting demand and expose queue delay. A durable backlog that waits ten minutes does not satisfy a two-second first-offer goal. Rate-limit retries, expire outdated requests and reserve capacity for acceptance and current-trip reads. Reconnecting phones should back off with randomness so a gateway restart does not overload authentication and storage together.

12Observe the user flow and the ownership rules

Monitor position age, discarded old updates, candidate-to-offer ratio, first-offer delay, acceptance commit latency, cancellation outcomes and notification lag. Split measurements by operating region and local density. Global averages hide the airport queue that is currently failing.

Check durable assignment invariants directly: no active driver appears in two assignments, no ride has two winners, and reciprocal driver/ride references agree. Test two rides competing for D17, two drivers competing for R501, cancellation during acceptance, and a lost response immediately after commit. Pause an old regional process during failover and verify that it cannot resume writing.

Protect location data through participant checks, short retention where possible and audited administrative access. Keep raw coordinates out of general request logs. Apply abuse controls to repeated ride creation and offer acceptance without treating a shared mobile network address as a reliable identity.

The main tradeoffs are deliberate: approximate discovery, regional assignment boundaries and latest-only coordinate delivery. The first simplifies high-volume search, the second keeps exclusive assignment understandable, and the third keeps slow clients current. State which requirements would force revisiting each choice instead of adding every possible service immediately.

13Check the design against its requirements

Use the numbered requirements to check the final design. FR refers to the functional list; NFR refers to the non-functional list. Performance rows specify tests still required, not achieved benchmark results.

14Rapid revision

Remember: GPS finds candidates; one transaction reserves both driver and ride. Protecting only one side permits a double assignment.

A strong closing answer follows R501 from creation to A77 and reconnect, then names the two acceptance races. Leave pooling, cross-region matching and billing as explicit extensions because they change which records must stay consistent, rather than merely adding traffic.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.