04QuestionsUber

04 · Worked prompt

Uber

Design nearby-driver discovery, matching, live locations, trip state, pricing, and regional failover.

40 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design nearby-driver discovery, matching, live locations, trip state, pricing, and regional failover.

DEFEND THE DIAGRAM

Trip state is authoritative; driver locations are TTL-indexed signals used to make one atomic assignment.

INTERVIEW CONTRACT

Design nearby-driver discovery, matching, live locations, trip state, pricing, and regional failover.

CAPACITY QUESTIONS TO QUANTIFY

City partitions · frequent GPS · seconds matching · strong trip ownership. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Rider + driver apps → Regional realtime edge
Request, offers, trip stream enters over HTTPS / RPC. Regional realtime edge handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Regional realtime edge → Matching/trip service → Trip DB
Matching/trip service receives the command, checks invariants and retry identity, then uses conditional assignment to update Trip DB. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Matching/trip service → Trip/location streams → Matching workers → Geo presence index
Matching/trip service emits publish after commit; Matching workers uses consume and project / update to build Geo presence index. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Regional realtime edge → Trip read service → Geo presence index / Trip DB
Trip read service uses optimized read for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Matching/trip service → Maps/ETA service
ETA batch crosses into Maps/ETA service. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.
06
Deliver without changing the source of truth
Matching workers → Trip fan-out → Rider + driver apps
Matching workers uses fan-out; Trip fan-out returns updates over WebSocket / push. Sequence IDs, reconnect cursors, and backpressure make delivery resumable without turning a socket into durable state.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Regional realtime edgeAuth + city routing	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Matching/trip serviceRank offers + assign winner	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Trip DBRequest, assignment, lifecycle	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Trip/location streamsRegion + entity partitions	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Matching workersGeo query + expiring offers	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Geo presence indexEligible drivers with TTL	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Trip read serviceState + latest locations	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Maps/ETA serviceRoad time + routes	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback
Trip fan-outOffers + lifecycle events	Connection and delivery state	Separates open connections and fan-out pressure from durable domain state.	Reconnect, ordering, slow consumers

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: SQL/distributed SQL owns trip/payment state; an in-memory H3/S2 index owns live driver locations; Kafka stores location/trip events.
Partitioning / sharding: Partition live supply by city + H3 cell; trip truth by trip/rider. A driver has one home region and monotonically newer location time.
Indexes: Cell→available drivers, driver current state, trips by rider/driver/time, and unique offer/accept command IDs.
Replication + consistency: Trip assignment is a strong conditional transition. Location and ETA are freshness-bounded TTL state.
Cache, queue + recovery: Location streams update geo shards; cache surge/ETA tiles briefly; every assignment reclaims availability conditionally.
Capacity math: Estimate updates/sec, active drivers/cell, requests/sec, radius expansion, city skew, and dispatch p99.
Alternative rejected: Relational geo indexes begin simply but churn under frequent updates; a TTL geo serving plane plus durable trip truth separates workloads.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Atomic assignment

Conditionally transition request and driver availability in the city owner

Two accepted offers must not create two trips

Location index

Map active drivers to adaptive spatial cells with TTL and update coalescing

Location is freshness-sensitive but not financial truth

Regional boundary

Keep trips owned by one home region and use degraded local continuation during control-plane loss

Multi-region active writes are not free

Failure pressure test

Show detection, containment, recovery, and evidence.

Driver disconnect

Expire presence and re-match only before trip ownership is final

stale driver count

Offer race

Accept under request version and reject losers deterministically

competing accepts

Map dependency degraded

Use cached ETA bands and preserve trip state operations

routing fallback rate

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize discover nearby available drivers and match and confirm one driver quickly.”
Scale
“The design changes around city partitions · frequent gps · seconds matching · strong trip ownership.”
Decision
“Atomic trip ownership matters more than globally consistent live location.”
Risk
“The first failure I want to pressure-test is: Stale location and double assignment can create unsafe trips.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Discover nearby available drivers
Match and confirm one driver quickly
Track trip state and live location
Price, pay, and survive mobile or regional failures

Uber · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

requested

matching

assigned

arriving

in progress

completed or cancelled

02Data model and APIs4 entities · 4 interfaces

Core entities

DriverPresencedriver_id, cell, location, observed_at, statusOwner: Location service

RideRequestrequest_id, rider, pickup, destination, stateOwner: Dispatch

DriverOfferoffer_id, driver_id, request_id, expires_atOwner: Offer service

Triptrip_id, rider, driver, state, versionOwner: Trip service

External interfaces

POST /v1/ride_requests

Create a request with pickup and destination

POST /v1/driver_offers/{id}/accept

Conditionally claim one active request

PATCH /v1/trips/{id}/state

Advance an allowed trip transition

POST /internal/drivers/{id}/locations

Update ephemeral position

03Deep dives and trade-offsChoose one

Atomic assignment

Conditionally transition request and driver availability in the city owner

Two accepted offers must not create two trips

Location index

Map active drivers to adaptive spatial cells with TTL and update coalescing

Location is freshness-sensitive but not financial truth

Regional boundary

Keep trips owned by one home region and use degraded local continuation during control-plane loss

Multi-region active writes are not free

04Failures, recovery, and evidence3 scenarios

Driver disconnect

Expire presence and re-match only before trip ownership is final

stale driver count

Offer race

Accept under request version and reject losers deterministically

competing accepts

Map dependency degraded

Use cached ETA bands and preserve trip state operations

routing fallback rate

05What makes the answer seniorInterviewer signals

Separate matching candidates from authoritative assignment
Frequent GPS writes should not hit the trip database
Describe the trip state machine before discussing surge pricing
Primary trade-off: Atomic trip ownership matters more than globally consistent live location.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Deliver without changing the source of truth

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Atomic assignment

Location index

Regional boundary

Show detection, containment, recovery, and evidence.

Driver disconnect

Offer race

Map dependency degraded

Reference details

Core entities

External interfaces

Atomic assignment

Location index

Regional boundary

Driver disconnect

Offer race

Map dependency degraded

Can you redraw it from memory?