System design interview question

Design Uber's nearby drivers

Uber, Lyft, Ola, any delivery app with a live map: “design Uber” is really about two data problems living side by side. One is a torrent of positions that are worthless seconds later; the other is trips and payments that must be exact for years. The interview tests whether you treat them differently. Here is how to walk into it, and then how to practise it until the answer is yours.

Practise Nearby Drivers

Multiple choicePick the design from four
Fill the gapsFill the gaps in one drawn for you
Build from scratchBuild it on a blank canvas

Practise it on a canvas

Free with an account.

The question, as an interviewer would set it

A ride-hailing app shows riders the drivers near them and matches each ride request to a close, available driver. Every active driver's phone reports its location every few seconds, which means hundreds of thousands of position updates a second at peak, and each one matters only until the next arrives. A rider asking for nearby drivers must get an answer in well under a second, and the answer must reflect where drivers are now, not where they were a minute ago. Completed trips, fares and payments, on the other hand, must be recorded exactly and kept for years, and a match must never assign the same driver to two riders.

What it is really testing

Every phrase that matters in the brief is a requirement in disguise. Spot them before you draw a single box.

“hundreds of thousands of position updates a second”
An ordered, replayable intake that absorbs a very high write rate.
“each one matters only until the next arrives”
Keep only the latest position, where losing one costs nothing.
“must get an answer in well under a second”
Search positions held in memory, indexed by area.
“recorded exactly and kept for years”
A durable, transactional record of trips and payments.
“never assign the same driver to two riders”
Claim the driver in one atomic step.

Back of the envelope

Drivers online at peak: 1 millionAn assumption to say out loud. If the interviewer has a number in mind, they will give it to you.
Position updates: One every 4 seconds → ~250,000 a secondEach one replaces the last; almost none of them needs to be kept.
Live map size: ~100 bytes per driver → ~100 MBSmall enough to hold entirely in memory. The hard part is the write rate, not the size.
Trips: ~20 million a day → ~230 a secondA tiny rate beside the positions, but every one must be exact and kept for years.

Questions to ask first

How often does a driver's phone report its position?
How many drivers are online at peak, and in how many cities?
How fresh must the rider's map be?
How is a driver chosen — nearest, fastest to arrive, or something else?
Are payments and trip history in scope, or only matching?

The trade-offs you will be pushed on

1.How do you find drivers within 2 km without checking every driver in the city?
2.Hundreds of thousands of positions arrive a second. Where do they land first, and who reads them?
3.Two riders request the same driver at the same moment. What decides who gets them?
4.A driver's phone goes silent. What should riders see?

Now answer it

The same design always gets the same score, with the reason behind every requirement — then defend it against the trade-offs above.