Design Uber

Question 1

Who is on each end of a match?

Accepted Answer

There are two clients here with completely different traffic patterns: drivers write constantly, riders read occasionally.

Question 2

What do the apps connect to?

Accepted Answer

A gateway is where the two very different workloads get separated and routed at all.

Question 3

Five million drivers ping every four seconds. Where does that go?

Accepted Answer

That is 1.25 million writes a second of data that is worthless four seconds later. It belongs in an in-memory geospatial index — geohash or quadtree cells in something like Redis — not in a database that will try to make it durable.

Question 4

Two riders request at the same instant and the same driver is nearest. Who decides?

Accepted Answer

Matching is its own service because it needs a single decision point per driver. Without one you assign the same car twice and find out when both riders are waiting on the same corner.

Question 5

Where does the trip itself live?

Accepted Answer

The trip outlives the app session, the connection and the index. It is the durable record in a design where most of the data is deliberately not.

Question 6

A match is made. What else needs to know?

Accepted Answer

Notifications, receipts, driver stats and fraud checks all care about a completed match, and none of them should be able to slow it down. Emit the event and let them read it.

Question 7

Your app writes to the trips store directly. What stops a modified client writing anything it likes?

Accepted Answer

The app is on someone else’s phone and can be edited. Every write has to go through something you control.

Question 8

How many location updates a second?

Accepted Answer

5,000,000 drivers divided by a 4 second interval is 1.25 million writes a second. Realising the write path is 100,000× the ride rate is the insight the whole design turns on.

Question 9

Why is driver location not in the same store as the trips?

Accepted Answer

Because they have opposite requirements. Locations are enormous in volume, worthless within seconds, and queried by proximity. Trips are rare, permanent, and queried by id. One store cannot be good at both.

Blueprint — system design