System design interview guide
Uber System Design: Matching, Live Location and Trip State
Short answer
Uber system design has four layers. The rider and driver apps send requests through an API gateway. They receive updates over one push stream, Uber's RAMEN platform, instead of polling. A trip platform owns every trip as a state machine. Since 2021 it stores trips and driver sessions in Google Cloud Spanner, so an accept is one transaction. Matching reads driver positions held in memory, bucketed into map cells such as H3 hexagons. It ranks free drivers by ETA from a routing engine corrected by the DeepETA model. Kafka carries events to billing and analytics.
Two courses by the author of this page:
770 lessons · 18 free to read
₹1,111 in India · $25 elsewhere, once
Get System DesignYou own this course
214 lessons · 10 free to read
₹1,333 in India · $35 elsewhere, once
Get Generative AI and Agentic AIYou own this course
Save your progress and get the interview checklist PDF
Uber's trip platform handles more than a million concurrent users. It runs billions of trips a year in over ten thousand cities. Its push platform holds more than 1.5 million open connections. One of its caches answers over 40 million reads a second.
Designing Uber is about state that changes every few seconds and must still be right. Drivers move all the time, so their locations live in memory, bucketed into map cells. A ride request becomes an entity with a strict life cycle: requested, offered, accepted, on trip, completed. Several actors change it at once: the rider, the driver, the matching system and timers. Uber has published most of its answers. H3 hexagons, its own map grid, measure supply and demand. A routing engine plus a machine learning model gives ETAs. A push platform replaces polling. Since 2021, Google Cloud Spanner holds trip state. One transaction is easier to reason about than a chain of best-effort writes.
Where it shows up
One of the most common system design interview questions. It also appears as design Lyft, design Ola, design a ride-hailing app or design a food delivery dispatcher. Uber has published how most parts work, so interviewers expect real choices, not three generic boxes.
Spec sheetUber
- 01Concurrent users
- 1M+
- 02Location writes, estimated
- ~125K / s
- 03Push messages
- 250K / s
- 04Cached reads
- 40M+ / s
worked through below, with the maths
Uber in its own numbers
Every figure below is quoted from Uber's own engineering writing. Tap a source to check it.
1M+
concurrent users on the trip platform
Uber Engineering, 202110,000+
cities, billions of trips a year
Uber Engineering, 20211.5M+
open push connections, 250,000 messages a second
Uber Engineering, 202040M+
reads a second served by the CacheFront cache
Uber Engineering, 202499.99%
availability target for the new trip platform
Uber Engineering, 2021#1
DeepETA is the highest-traffic model at Uber
Uber Engineering, 2022
in this guide
Design Uber, part by part
8 parts open to everyone · 3 with a free account · 3 with the course
You can read 8 of 14 parts. A free account opens the deep dive; the course opens all of it.
- Requirementsopen
- Scale estimatesopen
- High-level architectureopen
- One ride request, step by stepopen
- Core componentsopen
- Data modelfree account
- Deep dives (7)free account
- Trade-offs to discussfree account
- What the interviewer asks nextwith the course
- The interview scorecardwith the course
- Mock interview on this questionwith the course
- How Uber actually does itopen
- Frequently asked questionsopen
- Interview readiness checkopen
The hard parts of this design are taught step by step in the System Design course: Geospatial Indexing, Consistent Hashing and Gossip Protocol.
Why this question is asked
Design Uber packs four hard problems into one hour. You need a geospatial index for fast-moving points. You need a matcher that never gives one driver two trips. You need a way to tell phones about changes without polling. And you need a trip state machine that stays correct when phones drop off the network. Some candidates store every GPS ping in a SQL table, or poll every second. That tells the interviewer they have not thought about the load.
What the interviewer asks
“Design a ride-hailing service like Uber. A rider asks for a ride from A to B. Nearby drivers get the request and one accepts. Both see each other on a live map until the trip ends and the rider pays.”
Ask these back before you draw
- 1.Rides only, or food delivery too? (Start with rides; the same platform serves both at Uber.)
- 2.How many concurrent riders and drivers? (Use Uber's public numbers below, then state your own assumptions.)
- 3.How fresh must the driver's position be on the rider's map? A few seconds is the usual answer.
- 4.Is pricing in scope, including surge? Is payment in scope, or a separate service?
- 5.Do we need scheduled rides and shared rides, or only on-demand single rides?
This page is the free part.
The course goes deeper on the Uber design
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers the Uber design across a run of lessons, not one page. These 4 alone are about 107 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
- Geospatial Indexing
How databases efficiently answer 'find everything near me'. R-trees, geohashes, and spatial queries.
- Consistent Hashing
The algorithm that makes adding or removing nodes cheap, an interview favorite and production essential.
- Gossip Protocol
How gossip protocols spread cluster state like a rumor, in O(log N) rounds. Includes a Python simulator, SWIM failure detection and Cassandra.
- Server-Sent Events (SSE)
One-way server push over HTTP, real-time updates without the complexity of WebSockets.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
You own this course
Continue with Geospatial Indexingpay once,
yours for life
Live from the course bench
Before you design Uber, try the questions it rests on.
Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.
01Requirements
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- A rider sees nearby cars and an ETA before requesting
- A rider requests a ride from a pickup point to a drop-off
- Nearby drivers get an offer; exactly one can accept it
- Rider and driver see each other move on the map until pickup and during the trip
- The fare is shown up front and charged at the end of the trip
- Either side can cancel, and timeouts move the trip on by themselves
- Rider and driver rate each other afterwards
Non-functional requirements
- Matching and offers in seconds, not minutes
- Driver positions on the map a few seconds old at most
- Strong consistency on trip state: one driver, one trip, no lost acceptances
- Availability of at least 99.99% for the trip platform, Uber's own target
- Survive the loss of a zone or a region without losing trip data
- Work on slow 2G and 3G networks with drivers online for hours, so data use must be small
02Scale estimates
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Concurrent users
1M+
Uber's 2021 figure for the trip platform: more than a million concurrent users. It runs billions of trips a year across more than ten thousand cities.
Location writes, estimated
~125K / s
Our assumption, not Uber's: 500,000 drivers online at a busy hour, each sending a GPS point every 4 seconds. 500,000 / 4 = 125,000 writes a second, held in memory, never in the trip database.
Push messages
250K / s
Uber's push platform sent more than 250,000 messages a second over more than 1.5 million open connections (2020).
Cached reads
40M+ / s
Uber's CacheFront answers more than 40 million reads a second across its Docstore databases (2024). One use case alone ran 6 million a second.
Route time
< 100 ms
Uber's 2015 routing post sets the route time below 100 milliseconds at the 99th percentile. It runs before every dispatch.
03Architecture
High-level architecture
Draw four layers. At the top are the rider app and the driver app. Each sends requests through an API gateway. Each also keeps one long-lived stream open to the push platform, which Uber calls RAMEN, for updates. In the middle is the trip platform, which Uber calls Fulfillment. It models each trip and each driver session as an entity with a state machine. It is the source of truth for trip state. It asks the matching system for candidate drivers. Matching works on driver locations held in memory. In this design they are bucketed into H3 hexagons, Uber's map grid. It ranks candidates by ETA, which comes from a routing engine corrected by a machine learning model called DeepETA. At the bottom is storage. Since the 2021 rewrite, trip and driver entities live in Google Cloud Spanner. So one accept can change several entities in one transaction. Other services read through Docstore, Uber's MySQL-based database, with the CacheFront cache in front. Events go to Kafka for billing, analytics and offline datasets.
In a real interview, sketch this on the whiteboard before diving into any single box.
Interactive
Request a ride, step by step
The same layers, one ride at a time. Each step lights up the part doing the work. Then press Break it. Replay it with the driver's phone dropping off, or with two changes racing for one driver.
One Uber ride request
Normal ride, step 1 of 9
Seven parts on one board
The rider and driver apps send requests through the gateway and receive updates from push. The trip platform, which Uber calls Fulfillment, owns every trip. Matching finds drivers. Spanner stores trips and driver sessions.
Normal ride, step 2 of 9
The rider taps request
The rider app sends the pickup, the drop-off and the product through the API gateway. It reaches the trip platform's own gateway as a trigger: a named action that may change an entity's state.
Normal ride, step 3 of 9
A trip is born
The trip platform creates a trip entity in the requested state. Uber models each entity as a statechart, a state machine whose states can hold smaller state machines. The write is one Spanner transaction.
Normal ride, step 4 of 9
Find the right driver
Matching reads free drivers near the pickup. Their positions live in memory. In this design they are bucketed into H3 hexagons, so it reads a few cells, not the whole city. It ranks them by ETA on the road, not by straight-line distance.
Normal ride, step 5 of 9
Save the offer and its timer
The trip platform links the offer to the chosen driver and saves it. The expiry timer is written in the same transaction, as a row in Uber's LATE table, so it cannot be lost if a server dies right after the commit.
Normal ride, step 6 of 9
No polling
The driver app already holds an open stream to Uber's push platform. The offer goes down that stream with a sequence number. The driver's phone does not have to ask every few seconds.
Normal ride, step 7 of 9
The driver accepts
The driver taps accept. The accept goes back up through the gateway as another trigger, this time on the trip and on the driver's session.
Normal ride, step 8 of 9
One transaction, two entities
The trip moves to accepted and the driver's session moves to on trip, together. Before 2021 this took a saga of separate writes to Cassandra; now Spanner commits both or neither.
Normal ride, step 9 of 9
The rider sees the car
A follow-up action from the same commit tells push to message the rider: who is coming, the car and the ETA. From now on both apps receive positions over their streams.
Driver's phone drops, step 1 of 4
The offer goes out
Replay the offer. Push writes it to the driver's stream as message 3. The app has confirmed everything up to message 2.
Driver's phone drops, step 2 of 4
The signal drops
Message 3 was written to the connection but never reached the phone. In Uber's first push protocol the server sent a one-byte heartbeat every 4 seconds. With nothing for 7 seconds, the app knows the connection is dead.
Driver's phone drops, step 3 of 4
Reconnect from the last number
When the signal returns, the app reconnects and sends the highest sequence number it saw: 2. That number also acknowledges messages 1 and 2, so the server can forget them.
Driver's phone drops, step 4 of 4
Message 3 again
The server sends message 3 again, then anything newer. If the offer had expired meanwhile, the LATE timer would already have moved the trip on and matching would have tried someone else.
Two changes race, step 1 of 4
The driver goes offline
Replay with a different twist. The driver taps go offline at the end of a shift. That trigger wants to move the driver's session from open to offline.
Two changes race, step 2 of 4
Matching links an offer
In the same instant, matching picks this driver for a new trip and tries to link the offer. Uber gives this exact pair as an example of concurrent changes to one entity.
Two changes race, step 3 of 4
Only one commits
Both changes are Spanner transactions on the same driver row. Spanner serialises them: one commits first, and the other waits or is aborted, then re-reads and fails its check. In Uber's old Cassandra design, the last write won.
Two changes race, step 4 of 4
The loser retries cleanly
Here going offline won. The offer's transaction failed, so the trip is still requested and matching offers it to another driver. No driver ends up both offline and on a trip.
Based on Uber's engineering posts on the Fulfillment platform re-architecture (2021), the real-time push platform (2020), H3 and DeepETA. Uber has not published its exact matching rules; ranking by ETA follows its routing and DeepETA posts.
04One request
One ride request, step by step
The happy path of one UberX ride, using the parts Uber has described. Where Uber has not published a detail, the step says what this design does.
- 1
The rider requests
The rider app sends the pickup, the drop-off and the product to the API gateway. The request reaches the trip platform's own gateway as a trigger on a new trip entity.
- 2
The trip is created
The trip platform creates the trip in the requested state, in one Spanner transaction. It records any follow-up work, like an expiry timer, in the same transaction.
- 3
Matching finds drivers
In this design, matching looks up drivers in the H3 cells around the pickup and keeps the free ones. It ranks them by ETA from the routing engine and DeepETA.
- 4
The offer goes out
The trip platform links the offer to the chosen driver and saves it. The push platform sends the offer down the driver's open stream, with no polling.
- 5
The driver accepts
The accept updates the trip and the driver's session in one transaction. If the driver went offline at the same moment, only one of the two writes wins.
- 6
Both apps update
The push platform tells the rider who is coming. During pickup and the trip, both apps keep receiving positions and ETAs over their streams.
- 7
The trip ends
The driver ends the trip, the trip moves to completed, and events go out to billing, ratings and analytics.
05Components
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Rider and driver apps
Send requests through the API gateway and keep one push stream open. The driver app also sends its location regularly. Many drivers are on slow mobile networks for hours, so every byte counts.
API gateway
Every call from the apps passes through it. Uber also builds push messages through the same gateway endpoints. So a feature's logic is written once, for both pull and push.
Push platform (RAMEN)
Holds a stream to every app and delivers messages at least once. A service called Fireball decides when to push. Messages have a priority and a time to live of a few seconds up to 30 minutes. It has held over 1.5 million connections and sent over 250,000 messages a second.
Trip platform (Fulfillment)
The source of truth for trips and driver sessions. Each entity is a statechart, a state machine whose states can contain smaller state machines. Triggers come from apps, timers and other systems. A coordinator runs triggers on several entities in one transaction.
Location and matching
Driver positions are short-lived, so they live in memory, sharded across workers. Uber's Geospatial service, the first layer of matching, tracked every active driver this way. In this design, positions are bucketed into H3 hexagons so a nearby search reads a few cells. Uber built H3 for pricing and dispatch, but has not published the index Geospatial uses.
Routing and ETA
A routing engine computes a route and a first ETA on the road graph. DeepETA, a neural network, predicts the gap between that ETA and real arrival times. The uRoute service fronts every routing lookup.
Storage
Google Cloud Spanner for trip and driver entities since the 2021 rewrite. Docstore, Uber's MySQL-based database, for many other services, with CacheFront (Redis) in front for reads. Kafka carries events to billing and analytics.
Data model
trips (Spanner). In Uber's model, a trip has at least two waypoints. A waypoint is a place plus the tasks to do there. State changes run as statechart transitions inside transactions…
Every table for Uber, its keys, and which store fits it and why.
Deep dives
Finding nearby drivers: memory, H3 hexagons and matching. Driver positions change every few seconds, so a database write per ping is waste. Uber's Geospatial service, described in 2016 as the first layer of matching, kept every…
7 deep dives on the parts that break at scale, with 3 diagrams: Finding nearby drivers: memory, H3 hexagons and matching; ETAs: a routing engine plus a model that fixes its errors; Push, not polling: Uber's RAMEN protocol.
Trade-offs to discuss
Driver locations in memory vs in a database. Positions are replaced every few seconds and are worthless a minute later. Memory, sharded by driver, handles the write rate and serves nearby searches fast. A lost…
6 decisions an interviewer expects you to defend, each with the alternative and why it loses here.
What the interviewer asks next
Two riders' requests reach the same driver at the same moment. How do you stop a double booking?
6 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design Uber with the AI tutor.
10In production
How Uber actually does it
Everything here is from Uber's own engineering blog and its surge pricing page. The trip platform, its 2014 design and the Spanner rewrite are from the July 2021 post on Fulfillment. So are statecharts and LATE. The push platform and its protocol numbers are from the December 2020 post on RAMEN. H3 is from the 2018 post; the in-memory Geospatial service and Ringpop are from 2016. The routing numbers are from the 2015 routing post, and DeepETA from 2022. CacheFront is from February 2024, Docstore from 2021. Some posts are several years old, and Uber has changed details since. Say the year when you quote a number. Treat the location cadence and surge window on this page as assumptions.
Sources
- Uber Engineering: Fulfillment Platform, ground-up re-architecture (2021)
- Uber Engineering: Uber's Real-Time Push Platform (2020)
- Uber Engineering: H3, Uber's Hexagonal Hierarchical Spatial Index (2018)
- Uber Engineering: How Ringpop helps distribute your application (2016)
- Uber Engineering: DeepETA, how Uber predicts arrival times (2022)
- Uber Engineering: ETA Phone Home, how Uber engineers an efficient route (2015)
- Uber Engineering: How Uber serves over 40 million reads per second (2024)
- Uber Engineering: Evolving Schemaless into a distributed SQL database (2021)
- Uber Engineering: Designing Schemaless, part one (2016)
- Uber: how surge pricing works
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Geospatial Indexing
intermediate / database types storage
Consistent Hashing
intermediate / data replication distribution
Gossip Protocol
advanced / distributed systems core
Server-Sent Events
intermediate / messaging event systems
WebSockets
intermediate / messaging event systems
gRPC
intermediate / api design protocols
Finite State Machine
advanced / distributed systems core
Saga Pattern
advanced / distributed systems core
Distributed Transactions
advanced / distributed systems core
Change Data Capture
intermediate / data replication distribution
Cache Invalidation
foundation / caching strategies
Distributed Locks
advanced / distributed systems core
Idempotency
foundation / core fundamentals
Capstone: Design Uber Ride-Sharing
capstone / capstone
11FAQ
Frequently asked questions
interview readiness
Are you ready for Design Uber?
Three questions from this guide. Answer them without scrolling up, the way you would have to in the room.
Go deeper
This guide is built on these 6 lessons. Each one teaches one piece of the Uber design above, step by step.
- Geospatial IndexingSystem Design · database types storage · 16 min
- Consistent HashingSystem Design · data replication distribution · 25 min
- Gossip ProtocolSystem Design · distributed systems core · 50 min
- Server-Sent Events (SSE)System Design · messaging event systems · 16 min
- WebSocketsSystem Design · messaging event systems · 22 min
- gRPCSystem Design · api design protocols · 25 min
Practice with 770 system design lessons
Lifetime access for ₹1,111 in India or $25 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.
This one question is not enough for the interview.
Get all 200 questions in the System Design and Distributed Systems pack
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
NEWSystem Design Hands-On
Included in the System Design course: real systems, built live
Postgres Sharding: Complete Hands-On (PgBouncer + Citus). 2 h 36 min and 20 chapters: one PostgreSQL loaded until it breaks, then four shards behind a router you write, PgBouncer and Citus, with the 139-page slide deck. The first 15 minutes are free to watch.