Katkat
Back

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

VisaSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design the backend of an Uber-style ride-hailing service that matches riders with nearby drivers, streams live locations, and tracks trips to completion. It tests requirement scoping, geospatial indexing for moving drivers, race-free dispatch, real-time updates, failure handling, and the ability to lead a design discussion.

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.

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?

Hints

Hint 1

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 2

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.

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?