When people say "design Uber," they usually picture a map with cars moving around on it. The map is the easy part. The hard part is everything underneath: keeping track of where hundreds of thousands of drivers are right now, matching a rider to one of them in a second or two, and doing it in every city at once without the whole thing falling over during a Friday night surge.
Let me walk through how I would approach it.
The core problem is location. Every active driver sends their position every few seconds. That is a firehose of writes, and none of it is interesting for very long. A driver's location from thirty seconds ago is useless. So the first decision is that this data is hot, high-volume, and short-lived. You do not want it sitting in your main transactional database competing with payment records. It belongs in an in-memory store built for fast reads and writes, with old positions expiring on their own.
The next decision is how to answer the question a rider actually asks: "who is near me right now?" You cannot scan every driver in the country and measure distance. You need to bucket the world into cells so you only look at drivers in the rider's immediate area. This is where geospatial indexing comes in. Uber built and open sourced H3, a hexagonal grid system that divides the earth into cells. Hexagons are nice here because every neighbor is the same distance away, which makes "expand my search to the next ring out" clean and predictable. When a rider opens the app, you figure out their cell, pull the drivers in that cell and the ring around it, and rank them.
Matching is the part everyone underestimates. It is not just "nearest driver wins." You are running a small optimization problem. You care about estimated time to pickup, not raw distance, because a driver three blocks away facing the wrong direction on a one-way street is worse than one slightly further but pointed at you. You also have to avoid handing the same driver to two riders at once, which means matching needs a locking or reservation step. And you want to consider the whole neighborhood at once rather than greedily assigning each request, because batching produces better overall matches. This is a place where doing the naive thing works fine at small scale and quietly falls apart at large scale.
Then there is surge. Surge pricing is not a growth hack bolted on the side, it is a load-shedding mechanism. When demand in an area outruns supply, raising the price does two useful things at once: it pushes some riders to wait, which lowers demand, and it pulls drivers toward that area, which raises supply. From a systems point of view, surge is a feedback loop computed per geographic cell on a short interval. You are constantly measuring the ratio of open requests to available drivers in each area and adjusting a multiplier.
A few trade-offs are worth calling out honestly. You will denormalize aggressively. Trip history, driver profiles, and payments live in strongly consistent stores because money and disputes demand it. Live location does not, because being a little stale is fine and consistency would cost you speed you cannot spare. Splitting your data by how much consistency it actually needs is one of the most important calls you make, and it is easy to get wrong by treating everything as equally precious.
You also design around cities as natural shards. A trip in Bangalore has nothing to do with a trip in Chicago, so you can partition much of the system by region. That keeps the blast radius of a failure small and lets you scale hot cities independently.
How does the real Uber do it? Broadly along these lines. They run a services architecture, they use H3 for geospatial work, they lean on a dispatch system that thinks in terms of supply and demand per cell, and they keep live location separate from durable trip data. The details are far messier than any diagram, but the shape holds: a location firehose, a spatial index to answer proximity queries, a matcher that optimizes for pickup time, and pricing as a control loop.
If you can explain those four pieces and the reasons behind each choice, you understand the design. The map animation is just the part you can see.
I wrote the full breakdown, with diagrams and the data model, here: https://www.systemdesign.academy/interview/design-uber
Top comments (0)