Designing Uber System Design Interview — Geo-Indexing, Matching, and ETA

Designing Uber system design interview answers are judged on whether you can turn a messy real-time marketplace into clear services, data flows, and tradeoffs. The hard parts are geo-indexing nearby drivers, matching riders and drivers under supply constraints, computing reliable ETAs, and keeping the trip state machine correct when phones, networks, and humans behave unpredictably.

This guide gives a senior interview structure: what scope to clarify, what architecture to draw, how to explain geospatial lookup, how to rank matches, how to estimate ETA, and which failure modes interviewers usually probe.

Designing Uber system design interview: define scope first

The prompt "Design Uber" is too broad. Start by narrowing it without over-negotiating.

A good scope statement:

"I'll design the core ride-hailing flow for one region: riders request a trip, nearby available drivers are matched, both sides receive live location and ETA updates, the trip transitions from requested to accepted to picked up to completed, and the system records enough data for pricing and support. I will focus on geo-indexing, matching, ETA, and trip state correctness. I will leave payments, fraud, and full dispatch optimization as extensions unless you want to go there."

That statement proves you know the boundaries. It also buys you time to go deep on the three topics the interviewer probably cares about.

Key requirements:

• rider can request a ride with pickup and destination
• system finds nearby eligible drivers quickly
• driver can accept or timeout
• rider sees driver location and ETA
• driver sees pickup route and rider info
• trip state is durable and auditable
• location updates are high-volume but can tolerate small loss
• match/acceptance transitions need stronger consistency

Nonrequirements to park unless asked: multi-stop rides, carpool, driver incentives, surge pricing, international compliance, detailed payments, and dispatch ML.

Core architecture to draw

Use a simple service diagram first.

| Component | Responsibility | Notes | |---|---|---| | Rider API | request ride, cancel, view trip | low QPS compared with location stream | | Driver API | go online, accept, cancel, update status | authenticated driver app | | Location ingestion | accepts driver GPS pings | high write volume, lossy-tolerant | | Geo index service | stores recent available driver locations by cell | optimized for nearby lookup | | Matching service | ranks candidate drivers and sends offers | core business logic | | Trip service | owns trip state machine | durable, strongly consistent transitions | | ETA service | estimates pickup and route times | map graph, traffic, historical features | | Notification/dispatch | sends offers and status updates | push/WebSocket/SMS fallback | | Pricing service | estimates fare and surge | can be separate from matching | | Event stream | trip and location events | analytics, monitoring, replay where needed |

A clean data flow:

1. Driver goes online and sends location pings every few seconds.
2. Location ingestion validates ping and updates the driver's current cell in the geo index.
3. Rider requests a trip with pickup and destination.
4. Trip service creates a requested trip.
5. Matching service queries nearby available drivers from the geo index.
6. ETA service estimates pickup time and route quality for candidates.
7. Matching sends offers to drivers, either one at a time or in small batches.
8. First valid accept transitions trip to accepted and reserves the driver.
9. Driver/rider apps receive live status and location updates.
10. Trip service transitions through arrived, in_progress, completed, or cancelled.

The design principle: location updates are fast and approximate; trip and driver assignment states are authoritative.

Geo-indexing nearby drivers

The naive approach scans all drivers by latitude and longitude. That fails immediately. You need a spatial index that lets you query "drivers within roughly N kilometers of this pickup." In interviews, you can name geohash, S2, H3, or a custom grid; the important part is explaining the tradeoffs.

A practical approach:

• Divide the map into hierarchical cells.
• Store available drivers in the cell containing their latest location.
• For a pickup point, query its cell and neighboring cells.
• If not enough candidates appear, expand to a larger radius or coarser cell level.
• Filter candidates by exact distance, vehicle type, driver status, and freshness of location.

Driver location record:

| Field | Purpose | |---|---| | driver_id | unique driver | | lat/lng | latest location | | cell_id | geo index key | | heading/speed | useful for ETA | | status | available, offered, on_trip, offline | | vehicle_type | economy, XL, premium | | updated_at | freshness cutoff | | region_id | shard and policy boundary |

Location pings are ephemeral. Store current driver position in an in-memory or low-latency store keyed by region and cell. Also append sampled or compressed location events to a durable stream for analytics, safety, and ETA training. Do not make every GPS ping a strongly consistent database transaction.

Freshness matters. A driver location older than 10-20 seconds may be misleading in a dense city. A driver moving on a freeway may be close by distance but bad by route time. That is why geo lookup produces candidates, not final matches.

Matching: from nearby to best driver

The matching service should not simply pick the closest driver by straight-line distance. It should rank candidates by expected pickup time, driver availability, rider experience, marketplace health, and business rules.

Candidate filters:

• vehicle type requested
• driver is available and not already offered too many times
• location is fresh
• driver is within maximum pickup ETA
• driver meets safety/compliance constraints
• driver can legally serve pickup region

Ranking features:

| Feature | Why it matters | |---|---| | Pickup ETA | rider wait time is core experience | | Driver acceptance probability | far or low-value offers may be ignored | | Route compatibility | driver heading may make nearby driver impractical | | Driver idle time | fairness and supply utilization | | Cancellation risk | avoid matches likely to fail | | Destination or zone constraints | some drivers have preferences or regulations | | Marketplace balance | prevent starving nearby high-demand zones |

Dispatch strategy options:

1. Serial offer. Offer to best driver, wait a few seconds, then next. Simple and avoids multiple drivers thinking they have the ride, but slower if drivers ignore offers.
2. Small batch. Offer to top K drivers; first accept wins. Faster, but can annoy drivers and creates race handling.
3. Hybrid. Serial for dense markets and high confidence; small batch when demand is urgent or acceptance probability is low.

In the interview, pick one and discuss tradeoffs. A strong default is serial or small-batch with explicit reservation logic. When an offer is sent, mark driver status as offered with a short TTL. If they do not accept in time, they return to available. If they accept, Trip service atomically assigns the driver if the trip is still requested and driver is still eligible.

The invariant: one trip has at most one assigned driver; one driver has at most one active trip. Enforce that in the durable trip/driver state, not only in memory.

ETA: pickup and trip time estimation

ETA is where candidates often hand-wave. For the interview, you do not need to build Google Maps. You need to show that ETA is a service with inputs, outputs, and feedback loops.

Pickup ETA inputs:

• driver current location, heading, speed, and freshness
• pickup location
• road network travel time, not straight-line distance
• live traffic or recent speed by road segment
• historical time-of-day patterns
• driver-specific factors only if fair and allowed
• pickup complexity such as airport, venue, or one-way streets

Trip ETA inputs:

• pickup and destination
• route alternatives
• traffic
• time of day and day of week
• weather or event signals if available
• real-time route progress after pickup

A simple architecture: an ETA service queries a map/routing engine for candidate travel times, applies traffic multipliers and learned correction factors, and returns estimates with confidence. Matching can call ETA for the top candidates from geo lookup rather than for every nearby driver.

Decision rule: use fast approximate ETA for first-pass ranking, then more expensive route-aware ETA for top candidates. That avoids overloading the routing service during demand spikes.

Track ETA quality with metrics:

• predicted pickup ETA vs actual arrival time
• bias by city, hour, weather, and driver speed
• rider cancellation rate by ETA bucket
• driver acceptance rate by pickup ETA
• percentage of stale-location matches

ETA is both a product promise and a matching feature. Bad ETA creates cancellations, support tickets, and driver frustration.

Trip state machine

The trip service should own durable state transitions. Example states:

| State | Meaning | Next states | |---|---|---| | requested | rider has requested ride | matching, cancelled, expired | | matching | system is offering drivers | accepted, cancelled, no_driver_found | | accepted | driver assigned | driver_arrived, driver_cancelled, rider_cancelled | | driver_arrived | driver at pickup | in_progress, cancelled, no_show | | in_progress | rider picked up | completed, emergency, cancelled_with_fee | | completed | trip ended | paid, support_review | | cancelled | terminal cancellation | support_review |

Use compare-and-swap transitions or database constraints to avoid races. If two drivers accept a batch offer, only one requested -> accepted transition should succeed. The loser receives a polite "ride no longer available" response.

Driver state should be consistent with trip state:

• online_available
• offered
• assigned
• en_route_pickup
• on_trip
• offline

Some teams model driver assignment in the same database transaction as the trip transition. Others use a reservation service. Either works if you can state the invariant and enforce it under concurrent accepts.

Live location and communication

Live driver location shown to the rider is a streaming problem, not a ledger problem. Use WebSockets, server-sent events, or mobile push depending on app state. The location path can tolerate occasional dropped updates because the next ping supersedes the previous one.

For scale:

• shard location ingestion by region or driver_id
• throttle updates when app is backgrounded or movement is low
• compress or sample durable location history
• keep current location in a fast store with TTL
• publish trip-specific location updates only to authorized rider and driver sessions

Privacy and safety matter. Do not expose exact rider destination to all candidate drivers before acceptance if product policy forbids it. Do not let arbitrary users subscribe to driver locations. Keep audit logs for support and safety investigations.

Failure modes interviewers will ask about

Driver accepts but network drops. The accept request either reaches Trip service and commits or it does not. Driver app can query current assignment on reconnect. Do not rely only on push notifications.

Two drivers accept. Atomic trip assignment; first transition wins. Other accept fails gracefully.

Driver location is stale. Filter by updated_at; degrade to larger candidate search; do not match if no fresh drivers meet the threshold.

No drivers nearby. Expand radius, show longer ETA, offer scheduled ride, or fail quickly with clear UX. Do not spin forever.

Rider cancels during matching. Trip moves to cancelled; outstanding driver offers become invalid. Accept attempts check trip state.

Driver cancels after acceptance. Return trip to matching if rider still wants ride, maybe with priority and compensation logic.

Region surge. Pricing can publish demand/supply signals to Matching, but do not make surge a hidden side effect inside trip state. Keep pricing explainable.

Location spike during events. Backpressure location ingestion by dropping stale pings, not by delaying trip-state transitions.

Scale and storage choices

A city-level ride system has uneven traffic. Morning commute, rain, concerts, and airport closures create hotspots. Shard by region/city for operational isolation. Within a city, shard location data by geo cell or driver id. Trip data can be partitioned by trip_id, with secondary indexes for rider_id and driver_id.

Use different consistency levels for different data:

• Strong consistency: trip assignment, driver active-trip invariant, payment handoff, cancellation fee state.
• Eventual consistency: rider map display, driver heatmap, analytics, historical location traces.
• Low-latency cache: current driver locations and availability candidates.
• Durable log: trip events, state changes, support audit trail.

Metrics to mention:

• request-to-match latency
• match acceptance rate
• pickup ETA prediction error
• rider cancellation before pickup
• driver cancellation after accept
• stale driver location rate
• no-driver-found rate by cell/time
• concurrent accept conflicts

These metrics prove that the design is operable, not just drawable.

Interview script and prep checklist

Use this sequence in the interview:

1. Clarify scope and choose core ride-hailing flow.
2. State invariants: one driver per active trip, one active trip per driver, fresh locations for matching.
3. Draw services: Rider/Driver API, location ingestion, geo index, matching, ETA, trip service, notifications.
4. Walk happy path from driver online to trip completed.
5. Deep dive geo-indexing: cells, neighbor search, freshness, exact filtering.
6. Deep dive matching: filters, ranking, serial vs batch offers, reservation TTL.
7. Deep dive ETA: approximate first pass, route-aware top candidates, feedback metrics.
8. Explain state machine and concurrent accept handling.
9. Close with scaling and failure modes.

If you have experience to put on a resume, phrase it around real-time systems and marketplace correctness:

• Built geo-indexed dispatch service for low-latency nearby-resource lookup with freshness filters.
• Designed state machine and reservation flow that prevented double assignment under concurrent accepts.
• Improved ETA accuracy by comparing predicted pickup times with actual arrivals and tuning route features.

The strongest Uber design answers are not the ones with the most services. They are the ones with crisp boundaries: approximate location data feeds candidate search, ETA turns candidates into ranked options, matching handles marketplace tradeoffs, and Trip service enforces the assignment truth. Keep those boundaries clear and the interview becomes much easier.

Related guides

• Designing a Chat System Design Interview — WebSockets, Presence, and Message Storage — A system design interview guide for chat applications, covering WebSockets, fanout, message ordering, presence, storage, delivery receipts, media, search, scaling, and common trade-offs.
• Designing a Payment System Design Interview — Idempotency, Ledgers, and Reconciliation — A senior payment-system design answer lives or dies on idempotency, double-entry ledgers, and reconciliation. This guide gives the architecture, state model, failure-mode answers, and interview script.
• Designing a Search System Design Interview — Inverted Index, Ranking, and Recall — A practical system design guide for search interviews, covering inverted indexes, crawling and ingestion, query execution, ranking, recall, freshness, personalization, scaling, and evaluation trade-offs.
• Designing a URL Shortener System Design Interview: Capacity, Encoding, and Analytics — URL shortener is the most-asked warm-up system design question and the easiest to under-deliver on. Here's how to walk the full loop — capacity math, base62 encoding, caching, and analytics — without hand-waving.
• Backend System Design Interview Cheatsheet in 2026 — Patterns, Examples, Practice Plan, and Common Traps — A backend System Design interview cheatsheet for 2026 with the core flow, architecture patterns, capacity heuristics, reliability tradeoffs, and traps that separate senior answers from vague box drawing.