Design a Ride-Hailing App: System Design Interview Practice

Design a Ride-Hailing App as a system design interview question: Riders request a ride; the system finds a nearby available driver, tracks the trip and…

How do you answer "Design a Ride-Hailing App" in a system design interview?

Drivers send their location every few seconds to a location service that keeps only the latest position in memory, indexed by a geospatial grid such as geohash cells. A ride request searches the rider's cell and its neighbours, ranks nearby drivers by ETA and offers the trip to one driver at a time. The trip then moves through a state machine stored in a database.

  • Level: Advanced
  • Scored out of: 100
  • Cost: Free to read; a free account gets the review

Riders request a ride; the system finds a nearby available driver, tracks the trip and charges the rider.

The scale

1 million active drivers sending a location every 4 seconds; 20,000 ride requests a minute at peak.

What a strong answer covers

  1. Requirements (20 points). States the functional requirements in scope and the non-functional ones that drive the design (scale, latency, availability, consistency), and leaves out what is out of scope.
  2. Scale estimates (15 points). Turns the stated scale into requests per second (average and peak), storage and bandwidth, with the arithmetic shown, and uses the numbers to make a decision.
  3. API and data model (20 points). Defines the main API calls with their inputs and outputs, and a data model whose keys and store fit the access patterns.
  4. Architecture (25 points). Chooses components that fit the requirements and explains how a request moves through them, for the main read and write paths.
  5. Bottlenecks and trade-offs (20 points). Names the real bottlenecks and failure points at this scale and how the design handles them, weighing the alternatives (consistency vs availability, push vs pull, cost).

How the practice works

Write your design in sections — functional and non-functional requirements, scale estimates, the API, the data model, the request flow and a deep dive on the bottlenecks — and pick the components to draw the architecture. A review scores it on the five areas above in under a minute, then you can defend it in an AI mock interview.

The reference design

Design a Ride-Hailing App (Uber): the walkthrough, with animated figures.

Common questions

How do you answer "Design a Ride-Hailing App" in a system design interview?

Drivers send their location every few seconds to a location service that keeps only the latest position in memory, indexed by a geospatial grid such as geohash cells. A ride request searches the rider's cell and its neighbours, ranks nearby drivers by ETA and offers the trip to one driver at a time. The trip then moves through a state machine stored in a database.

What scale is "Design a Ride-Hailing App" designed for here?

1 million active drivers sending a location every 4 seconds; 20,000 ride requests a minute at peak. Your estimates turn that into requests per second, storage and bandwidth before you pick components.

How is a design scored?

Out of 100 on a fixed rubric: requirements (20), scale estimates (15), api and data model (20), architecture (25), bottlenecks and trade-offs (20). The review names what the design covered and what it missed, then points to the reference design.

Is "Design a Ride-Hailing App" a good first system design problem?

It is rated advanced. Start with the beginner problems — the URL shortener and the rate limiter — and the System Design notes on load balancing, caching and sharding first.

Do I need an account?

Not to read the problem or the reference design. Getting your design reviewed needs a free account.

More design problems