Design Uber

Two hundred thousand drivers are moving around a city, and every one of their phones reports where it is every four seconds. A rider opens the app and wants to see the nearest cars. Thirty seconds later they want exactly one of those cars, promised to them and to nobody else.

Look at the two halves of that picture. They are two different systems sharing a screen:

• The driver half (driver app, gateway, geo index) takes fifty thousand location updates a second, and it is allowed to lose all of them, because a fresh one arrives four seconds later.
• The rider half (rider API, matching, trip store) handles about a thousand ride requests a second, and it is never allowed to lose one, because a trip is money and a legal record.

Most candidates design the driver half and hand wave the rider half. The rider half is where the interview is.

Step 1: Understand the problem#

Ask about the matching before you ask about the map. Finding nearby points on a map is a solved problem with a known answer. Deciding which driver gets which rider is where the real decisions are. Each row below settles one line of the design.

What you are building, and what you cut#

Back of the envelope#

Read the last two rows together. Fifty thousand writes a second sounds huge, but the whole city's live state is a few hundred megabytes, smaller than one phone photo album. That pairing is the design: everything fits in memory, and nothing on the hot path ever touches a disk.

Step 2: Propose the high level design#

The API#

Four calls. The first runs fifty thousand times a second, so it is as small as an API call can be. The last one is where two drivers can collide.

{
  "driverId": 88213,
  "lat": 12.9352,
  "lng": 77.6245,
  "heading": 138,
  "at": "2026-09-10T09:14:22Z"
}

{
  "riderId": 4471,
  "quoteId": "q_71a2",
  "pickup": {...},
  "dropoff": {...}
}

The data model#

Two stores, and the split between them is the design. The first holds where drivers are right now. The second holds trips. A geohash (used as the key below) is a short string that names a square on the map: tdr1vx is one square about 1.2 km wide, and points close together usually share the same string. Design a proximity service shows how a search covers a circle with these squares.

The version column is an optimistic lock: every change says "update this row only if the version is still 7", so two writers racing on one row cannot both win. The optimistic vs pessimistic locking article shows the race step by step.

The whole system on one whiteboard#

Figure 1 is the picture at the top of the page, with maps and payments added.

Walking Figure 1:

1. Driver apps keep one connection open and stream their position through it. Opening a fresh HTTPS request every four seconds for 200,000 drivers is a denial of service attack you run on yourself. Which kind of long lived connection to use is the subject of WebSockets vs SSE vs long polling.
2. The gateway overwrites the driver's entry in the geo index. No append, no history, no disk. If the driver crossed into a new square, that is a remove from the old one and an add to the new one.
3. A rider opens the app and asks who is nearby.
4. That search reads the same in memory index the drivers write into, keeping only drivers who are available.
5. The price is quoted once, here, and frozen into a quote id. It cannot drift between looking and accepting.
6. Requesting a ride hands the problem to the matching service, which answers at once with a trip in the matching state. No driver has agreed yet, which is why the API returns 202.
7. Matching reads candidate drivers from the index and ranks them by ETA (estimated time of arrival), not by straight line distance, because a river or a one way street makes those two numbers very different.
8. The trip row is created before any driver is contacted. If everything crashes now, there is a durable record saying a rider is waiting.
9. An offer goes to one driver with a short expiry, and a timer owns what happens if they do not answer. That timer is the part people forget, and it is the difference between a system and a demo.

Step 3: Design deep dive#

Finding nearby drivers without a spatial database#

Picture a city map with a grid drawn over it. To find cars near you, you do not measure the distance to every car in the city. You look in your own square and the squares touching it. That is the whole trick, and the ladder below is how you arrive at it.

The three ways of cutting up the map, side by side:

In the interview, start with geohash cells and say why: it is a hash map of sets, a write is two operations, and nothing needs rebalancing under load. Then name its weakness before the interviewer does, which is that a fixed cell size is wrong somewhere in every city, and say that S2 is what you move to when that starts costing you matches.

One driver, one rider, no exceptions#

This is the part that separates the answers. Two riders, two matching workers, one driver nearest to both, and nothing in the geo index stops both workers from picking that driver.

It is the cinema seat problem. Two people look at the seat map, both see seat 14C free, both tap it. The seat map was correct when each of them looked. What matters is who gets to change it.

Figure 2 plays the race with the third rung in place. A compare and set (CAS) is that atomic "change it only if it still equals what I saw" step.

Two details worth saying out loud. The lease has to expire on its own, so a matcher that crashes between the compare and set and the offer does not leave a driver stuck as offered for ever. And the accept has to be idempotent, meaning doing it twice has the same effect as doing it once, because a driver on a patchy connection will tap accept twice and both taps will arrive. Idempotency keys shows how that is built.

Sharding a city, and what happens at the edges#

Sharding means splitting the work so each machine owns one slice of it (the sharding chapter starts from the beginning). For matching, the natural slice is a piece of the map: the matcher that owns a region is the only one that changes the state of drivers inside it, which keeps the compare and set cheap and local.

Break it#

The stadium case is the one to talk about unprompted. Every geospatial system has it, the map makes it look like a new problem, and it is the same hot partition (one slice getting far more traffic than the rest) you would get from a celebrity account or a viral link. The sharding chapter has a Break it section on exactly this.

Trade-offs#

Interview replay#

Checkpoint#