system-design · intermediate

Design Uber — Matching Riders and Drivers

Start here

Design Uber (simplified) covers:

1. Rider requests a ride with pickup location
2. System finds nearby available drivers
3. Driver accepts; trip starts
4. Live location updates
5. Trip completes; payment

What you will learn

1. Scope MVP (no pooling, no food).
2. Model supply (drivers) and demand (riders).
3. Index drivers by location (geohash/quadtree).
4. Design match workflow and timeouts.
5. Handle location streaming efficiently.
6. Discuss surge as product+system note.

Words you need before we begin

Requirements

Functional MVP

• Request ride
• Match driver
• Driver accept/reject
• Live track driver
• Complete trip

Non-functional

• Match within a few seconds in dense cities
• Location freshness
• High availability for requests

Scale example

• 100k concurrent drivers in a large region
• Location updates every 3–5s → heavy write path

High-level design

flowchart LR
  Rider --> API
  Driver --> API
  API --> Match[Matching service]
  API --> Loc[Location service]
  Loc --> Grid[(Geo index)]
  Match --> Trip[(Trip store)]
  API --> Pay[Payments]
  API --> RT[Realtime gateway]

Step-by-step design

Step 1 — Location service

Drivers send pings. Service updates driverId → (lat, lng, status, ts) and indexes into geohash cells (or Redis GEO). TTL stale drivers out.

Step 2 — Request ride

Create trip REQUESTED with pickup/dropoff. Idempotency key from client.

Step 3 — Nearby search

Query ring of geohash cells around pickup; filter available; rank by distance/ETA/score.

Step 4 — Offer / accept

Offer to top driver(s) with timeout; on reject/timeout, next candidates; on accept, trip MATCHED.

Step 5 — Realtime

WebSocket channels for rider/driver trip room; push location and state changes.

Step 6 — Completion & payment

Trip COMPLETED; call payments with idempotency; receipts async.

Step 7 — City partitioning

Shard by city/region for independent scaling and data locality.

Failure modes

Trade-offs

Common mistakes

1. Putting all drivers in one SQL ORDER BY distance globally.
2. Ignoring ping write amplification.
3. No trip state machine.
4. Designing self-driving AI instead of dispatch.
5. Global single database for the planet on day one.

Check your understanding

1. Why geohash/grid for drivers?
2. What does a location ping contain minimally?
3. How to prevent two riders matching the same driver?
4. Why region/city shards?
5. Where does idempotency matter in payments?

Practice

1. Estimate pings/s for 50k drivers every 4s.
2. Draw match sequence with timeout.
3. Design keys for Redis GEO or geohash sets.
4. Discuss airport surge load.
5. Mock interview.

Deeper production notes

Map/ETA providers

Treat external map ETA as dependency with timeouts and fallbacks (haversine rough ETA).

Fraud & safety

Mention without deep dive: device trust, SOS—interview timeboxed.

Additional teaching scenarios

Scenario A — 10× peak

Scenario B — dependency down 30 minutes

Scenario C — interview wrap (5 sentences)

Revision summary

• Geo index supply; state machine trips.
• Location pings are a write-heavy design center.
• Match with timeouts and leases.
• Partition by city/region.

Glossary

Abbreviations and terminology

• ETA — Estimated time of arrival
• GPS — Global Positioning System
• TTL — Time to live

What to learn next

1. Design notification service
2. Consistent hashing
3. WebSockets

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Interview and production field guide for this topic

Use this section as deliberate practice, not filler. Rewrite the worked example for a second domain you know well—fintech, education, logistics, or media. Keep the same skeleton: requirements, estimates, high-level diagram, request path, data model, scale lever, failure modes, and trade-offs. If you cannot fill every section without copying buzzwords, you do not yet own the design.

Numbers to force yourself to state

Always speak order-of-magnitude figures: peak QPS, storage growth per day, fan-out factor, connection counts, or queue depth. Wrong numbers that are explicit beat silent hand-waving. Correct the numbers when the interviewer or teammate challenges them; that is collaboration, not failure.

Failure minute

Set a timer for sixty seconds and list only failures: timeouts, duplicates, hot keys, dependency outages, bad deploys, and data corruption paths. For each, name detection and first mitigation. Designs that only describe the happy path are incomplete for production and weak in interviews.

Ownership and operability

Name the dashboard, the alert, the runbook section, and the team that pages. If any are blank, the system will train you during an incident. Prefer progressive delivery: canaries, flags, and rollback notes written before the change lands.

Consistency and retries

State whether the design assumes at-least-once delivery, whether handlers are idempotent, and where unique constraints live. Retries without idempotency are how double charges, double messages, and duplicate fan-out jobs appear. Timeouts without bounds are how thread pools die.

What good looks like in a review

A strong design review or interview answer clarifies scope, makes assumptions audible, draws a minimal path, deepens one or two bottlenecks, and closes with trade-offs and evolution. Use that bar on design-uber round 0 every time you revisit it.

Interview and production field guide for this topic

Use this section as deliberate practice, not filler. Rewrite the worked example for a second domain you know well—fintech, education, logistics, or media. Keep the same skeleton: requirements, estimates, high-level diagram, request path, data model, scale lever, failure modes, and trade-offs. If you cannot fill every section without copying buzzwords, you do not yet own the design.

Numbers to force yourself to state

Always speak order-of-magnitude figures: peak QPS, storage growth per day, fan-out factor, connection counts, or queue depth. Wrong numbers that are explicit beat silent hand-waving. Correct the numbers when the interviewer or teammate challenges them; that is collaboration, not failure.

Failure minute

Set a timer for sixty seconds and list only failures: timeouts, duplicates, hot keys, dependency outages, bad deploys, and data corruption paths. For each, name detection and first mitigation. Designs that only describe the happy path are incomplete for production and weak in interviews.

Ownership and operability

Name the dashboard, the alert, the runbook section, and the team that pages. If any are blank, the system will train you during an incident. Prefer progressive delivery: canaries, flags, and rollback notes written before the change lands.

Consistency and retries

State whether the design assumes at-least-once delivery, whether handlers are idempotent, and where unique constraints live. Retries without idempotency are how double charges, double messages, and duplicate fan-out jobs appear. Timeouts without bounds are how thread pools die.

What good looks like in a review

A strong design review or interview answer clarifies scope, makes assumptions audible, draws a minimal path, deepens one or two bottlenecks, and closes with trade-offs and evolution. Use that bar on design-uber round 1 every time you revisit it.

FAQ from first-time learners

Q: SQL for locations?
A: Possible with specialty indexes; many interviews use Redis GEO/memory grid for hot supply.

Q: Global stream of all pings?
A: Prefer regional ingestion; avoid single worldwide hotspot.

Track: Distributed Systems

Previous: Design Search Autocomplete — Typeahead Suggestions

Next: Design WhatsApp — 1:1 and Group Messaging

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab