Requirements: Match Riders and Drivers - Uber Lyft Ridesharing | OneNoughtOne

0/273

System Design (HLD)Commerce & Infrastructure Systems

Uber / Lyft Ride-Sharing System Design

LevelAdvanced

Duration180 mins

TopicCommerce & Infrastructure Systems

1 / 6

Requirements: Match Riders and Drivers

The Real-Time Matching Challenge

At any given second, Uber operates across 10,000+ cities globally, processing over 25 million trips per day. This means roughly 290 ride requests per second on average, with peaks exceeding 1,000+ requests per second during rush hours. For each request, the system must perform a seemingly simple task: find a nearby driver and connect them with a rider.

But beneath this simplicity lies extraordinary complexity. The system must track millions of moving vehicles in real-time, match riders to optimal drivers within milliseconds, handle payment processing, route calculation, fare estimation—all while maintaining 99.99% availability. A 15-second delay in matching can cause riders to abandon the app. A system outage during New Year's Eve could strand millions.

This is not just a matching problem—it's a distributed systems masterclass disguised as a consumer app.

What You Will Learn

By completing this module, you will be able to design a production-grade ride-sharing system from scratch. You'll understand how to handle real-time location tracking at scale, implement efficient rider-driver matching, calculate dynamic pricing, estimate accurate ETAs, and manage the complete trip lifecycle—all while maintaining the reliability that users expect.

Understanding the Ride-Sharing Domain

Before diving into technical requirements, we must deeply understand the ride-sharing domain. This understanding prevents building systems that are technically sound but miss fundamental business realities.

The Core Actors:

A ride-sharing platform serves as a two-sided marketplace connecting:

Riders — Users who need transportation from point A to point B
Drivers — Independent contractors who provide transportation using their personal vehicles

Unlike traditional taxi services where a company owns vehicles and employs drivers, ride-sharing platforms are pure software marketplaces. They own no vehicles and employ no drivers directly. This creates unique technical challenges around:

Supply elasticity: Driver availability fluctuates based on external factors (weather, events, time of day)
Geographic fragmentation: Supply and demand are hyperlocal—drivers in Manhattan don't help riders in Brooklyn
Real-time coordination: Both supply and demand are mobile, creating a constantly shifting optimization problem

Key Stakeholders and Their Needs
Stakeholder	Primary Needs	Success Metrics	Technical Implications
Riders	Quick pickup, accurate ETA, fair pricing, safety	Wait time < 5 min, price accuracy, 5-star experience	Real-time matching, accurate estimation, rating system
Drivers	Consistent earnings, efficient routing, fair dispatch	Earnings/hour, utilization rate, navigation quality	Load balancing, route optimization, transparent allocation
Platform	Market liquidity, unit economics, scalability	Trips/day, take rate, CAC/LTV ratios	High availability, fraud prevention, cost efficiency
Regulators	Safety, fair labor practices, accessibility	Incident rates, driver treatment, ADA compliance	Background checks, audit trails, accessibility features

Two-Sided Marketplace Dynamics

The platform must maintain a delicate balance. Too many drivers and not enough riders means drivers earn poorly and leave. Too many riders and not enough drivers means long wait times and rider churn. Surge pricing is fundamentally a mechanism to maintain this balance in real-time.

Functional Requirements

Functional requirements define what the system must do. For a ride-sharing platform, these span the complete user journey for both riders and drivers.

Rider-Side Functionality

The rider experience begins before the app is opened and extends beyond the trip completion:

Core Rider Features

•Account Management — Registration, login, profile management, payment methods, saved addresses, ride history
•Ride Request — Select pickup location (auto-detect or manual), select destination, choose ride type (economy, premium, shared), view fare estimate before confirming
•Driver Matching — System finds optimal driver, rider sees driver details, vehicle info, real-time ETA to pickup
•Trip Tracking — Real-time map showing driver en route, notifications for arrival, in-trip navigation visibility, share trip with contacts
•Payment Processing — Automatic fare calculation, multiple payment methods, tipping, receipt generation, fare splitting
•Rating & Feedback — Post-trip driver rating, issue reporting, lost item recovery, support ticket creation

Driver-Side Functionality

Drivers have fundamentally different needs focused on earnings optimization and operational efficiency:

Core Driver Features

•Onboarding — Document verification (license, insurance, vehicle registration), background check status, vehicle inspection scheduling
•Availability Toggle — Go online/offline, set destination preferences (driver heading home), view surge zones nearby
•Trip Dispatch — Receive trip requests with pickup distance and estimated fare, accept/decline within time limit, batch trip offers
•Navigation — Turn-by-turn directions to pickup, optimized route to destination, traffic-aware re-routing
•Trip Management — Mark arrived at pickup, start trip, end trip, handle rider no-shows, cancel with reason
•Earnings Dashboard — Real-time earnings today, weekly summaries, bonus/incentive tracking, instant cash-out options

Platform-Side Functionality

Beyond user-facing features, the platform requires extensive operational capabilities:

Platform Operations

•Dynamic Pricing — Real-time supply/demand analysis, surge multiplier computation, price transparency communication
•Fraud Detection — Fake GPS detection, payment fraud prevention, account abuse identification, driver collusion detection
•Safety Features — Real-time trip monitoring, emergency SOS button, abnormal route detection, speed monitoring
•Analytics & Reporting — Operational dashboards, regulatory compliance reports, financial reconciliation, driver/rider insights
•Customer Support — Ticket routing, refund processing, dispute resolution, escalation handling

Non-Functional Requirements

Non-functional requirements define how well the system must perform. For a real-time platform like Uber, these requirements are often more challenging than functional requirements.

Availability and Reliability

Ride-sharing is a mission-critical service for many users. When someone needs to catch a flight or get home safely at night, the app must work.

Availability Requirements by Component
Component	Target Availability	Max Downtime/Year	Justification
Core Matching Service	99.99%	52 minutes	Direct impact on revenue; each minute of downtime = millions in lost trips
Location Services	99.99%	52 minutes	Real-time tracking required for matching and safety
Payment Processing	99.95%	4.4 hours	Slightly more tolerant; can defer payment processing briefly
Driver App	99.9%	8.7 hours	Must function during internet connectivity issues
Analytics/Reporting	99.5%	1.8 days	Internal system; degradation acceptable

Latency Requirements

Latency directly impacts user experience and completion rates. Studies show that each additional second of wait time increases rider abandonment by 2-3%.

Latency SLAs for Critical Operations
Operation	P50 Target	P99 Target	P99.9 Target
Ride request to match confirmation	< 2 sec	< 5 sec	< 10 sec
Driver location update processing	< 100ms	< 500ms	< 1 sec
ETA calculation	< 200ms	< 1 sec	< 2 sec
Fare estimation	< 300ms	< 1 sec	< 2 sec
Map tile loading	< 100ms	< 500ms	< 1 sec

Scalability Requirements

The system must handle extreme load variations—from quiet Tuesday mornings to New Year's Eve peaks:

Scale Targets

•Concurrent active drivers: 5 million globally during peak hours
•Location updates: Each driver sends GPS every 4 seconds → 1.25 million location updates/second
•Ride requests: 1,000+ requests/second during peak, 10,000+ during major events
•Peak load handling: Must sustain 10x normal load during major events without degradation
•Geographic distribution: Serve 10,000+ cities with data locality for latency requirements

The Flash Crowd Problem

When a major event ends (concert, sports game), thousands of riders simultaneously request rides in a tiny geographic area. The system must handle these 'flash crowds' without cascading failures. This is often the hardest scaling challenge—not steady-state load but sudden, localized spikes.

Consistency Requirements

Ride-sharing has unique consistency challenges because it deals with real-world state (physical locations of cars and people) that must be reflected in system state:

Consistency Constraints

•Driver assignment must be strongly consistent — A driver can only accept one trip at a time. Double-booking creates terrible experiences for all parties.
•Payment processing must be exactly-once — Charging riders twice or paying drivers twice means financial loss and trust erosion.
•Location data can be eventually consistent — Slight staleness (1-2 seconds) is acceptable for location display; the world is inherently fuzzy.
•Trip state must be linearizable — The sequence of trip events (requested → matched → started → completed) must be totally ordered.

Back-of-Envelope Scale Estimation

Before designing systems, we must understand the scale we're targeting. Let's work through realistic estimates based on Uber's public data and reasonable assumptions.

Traffic Estimation

scale-estimation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
=== RIDE REQUEST VOLUME ===
 
Daily active riders: 20 million globally
Average rides per active rider per day: 1.25
Daily total rides: 25 million rides/day
 
Rides per second (average): 25M / 86,400 = ~290 rides/second
Peak multiplier: 4x average
Peak rides per second: ~1,200 rides/second
 
=== DRIVER LOCATION UPDATES ===
 
Active drivers at peak: 5 million globally
Location update frequency: 1 update per 4 seconds
Updates per second: 5M / 4 = 1.25 million updates/second
 
Each location update payload:
- driver_id: 8 bytes
- latitude: 8 bytes (double)
- longitude: 8 bytes (double)  
- timestamp: 8 bytes
- heading: 4 bytes
- speed: 4 bytes
- accuracy: 4 bytes
Total: ~50 bytes per update
 
Location data ingestion rate: 1.25M × 50 = 62.5 MB/second = 5.4 TB/day
 
=== MAP MATCHING AND ROUTING ===
 
Each ride requires:
- Initial ETA calculation: 1 call
- Route calculation at pickup: 1 call
- Re-routing during trip: ~2-3 calls average
 
Routing calls per ride: ~4-5 calls
Routing calls per second (peak): 1,200 × 5 = 6,000 calls/second
 
=== STORAGE ESTIMATION ===
 
Trip record size: ~2 KB (includes route polyline, payment details, etc.)
Daily new trip data: 25M × 2 KB = 50 GB/day raw
With indexes and replication: ~200 GB/day
 
Location history (for analytics):
- 1.25M updates/sec × 50 bytes × 86,400 sec = 5.4 TB/day raw
- Typically downsampled for long-term storage: ~500 GB/day

Infrastructure Implications

These numbers translate to concrete infrastructure requirements:

Infrastructure Requirements Summary
Component	Capacity Requirement	Technology Implications
Location Ingestion	1.25M writes/second	Kafka/Kinesis for buffering; time-series optimized storage
Spatial Queries	6,000+ queries/second	Geospatial indexing (R-trees, geohashes); in-memory caching
Matching Engine	1,200+ matches/second	Distributed state management; optimistic concurrency
Trip Database	50K+ reads/second, 25K+ writes/second	Sharded PostgreSQL or DynamoDB; read replicas
Real-time Push	10M+ active WebSocket connections	Dedicated push infrastructure; connection pooling

Interview Insight

In system design interviews, explicitly walking through scale estimation demonstrates engineering maturity. Interviewers want to see that you can translate business requirements into concrete numbers that drive architectural decisions. The specific numbers matter less than showing the methodology.

The Rider-Driver Matching Problem

At the heart of any ride-sharing platform is the matching problem: given a rider requesting a trip and a set of available drivers, which driver should be assigned?

This seemingly simple question has profound complexity:

Naive Approach: Nearest Driver

The intuitive solution is to find the closest available driver. But this approach has serious flaws:

Problems with Nearest Driver

•Physical distance ≠ travel time — A driver 500m away across a river may take 15 minutes; one 1km away on the same road takes 3 minutes
•Ignores driver trajectory — A driver moving toward you at 50 km/h is preferable to a stationary one closer by
•No global optimization — Assigning driver A to rider 1 might prevent optimal assignment for riders 2, 3, 4
•Fairness issues — Drivers in high-demand areas get all trips; outlying drivers never get requests

Optimal Matching Considerations

•ETA-based distance — Use actual travel time considering traffic, road network, turn restrictions
•Trajectory prediction — Model where drivers will be, not just where they are
•Batch optimization — Consider multiple riders and drivers simultaneously for global optimum
•Driver preferences — Account for driver's destination, earnings goals, and historical patterns

Matching as an Optimization Problem

The optimal matching problem can be formalized as bipartite graph matching with costs:

Vertices: Set of riders R and set of available drivers D
Edges: Connect each rider to all drivers within feasible pickup range
Edge weights: Estimated pickup time (or a composite score including ETA, driver rating, vehicle type match)
Objective: Minimize total weighted pickup time across all assignments

This is a variant of the assignment problem, solvable optimally using the Hungarian algorithm in O(n³) time. However, at Uber's scale with thousands of riders and drivers per city per second, this approach is too slow.

Real-World Matching Approach

In practice, ride-sharing platforms use hierarchical approaches: first filter to a small candidate set using spatial indexing (geohash cells), then run sophisticated matching/scoring within that subset. This reduces the problem from millions of possibilities to tens or hundreds, making advanced optimization feasible.

Matching Algorithm Tradeoffs

Different matching strategies offer different tradeoffs:

Matching Strategy Comparison
Strategy	Latency	Optimality	Fairness	Complexity
Nearest available (greedy)	Very low (~10ms)	Poor	Poor	Trivial
Lowest ETA (greedy)	Low (~50ms)	Moderate	Poor	Requires routing API
Batch matching (periodic)	Higher (100-500ms)	Good	Good	Moderate complexity
Real-time optimization	Medium (~100ms)	Near-optimal	Excellent	High complexity

Uber's Evolution:

Uber started with simple nearest-driver matching and progressively evolved:

2010-2012: Nearest available driver within radius
2012-2015: ETA-based matching with basic supply positioning
2015-2018: Batch matching with prediction models
2018-present: Real-time optimization with machine learning scoring, batched dispatch, and forward-looking optimization

This evolution reflects a general principle: start simple, instrument heavily, optimize iteratively. Premature optimization of matching would have delayed launch; over-simplified matching long-term would have hurt market efficiency.

Defining System Boundaries

A ride-sharing platform doesn't exist in isolation. Understanding what's in scope versus out of scope is critical for focused system design.

Core Platform (In Scope)

What We're Designing

•Location Services — Ingesting, storing, and querying real-time driver locations
•Matching Engine — Connecting riders with optimal drivers
•Trip Management — Handling trip lifecycle from request to completion
•Pricing Engine — Fare estimation, surge pricing, final fare calculation
•ETA Service — Estimating pickup times and trip durations
•Real-time Communication — Push notifications, in-app messaging between rider/driver

Supporting Services (Reference Only)

Adjacent Systems We'll Reference

•Maps & Routing — Assume access to a routing service (Google Maps, OSRM, or internal) providing ETAs and routes
•Payment Processing — Assume a payment gateway handling actual charges (Stripe, Braintree, or internal)
•Identity & Authentication — Assume user authentication is handled by an auth service
•Fraud Detection — Referenced but not deeply designed in this module

Explicitly Out of Scope

Not Covered in This Design

•Driver onboarding and document verification workflow
•Customer support ticketing system
•Marketing and promotional systems
•Internal analytics and data warehouse
•Food delivery (Uber Eats) or other verticals
•Autonomous vehicle integration

Interview Strategy: Scope First

In system design interviews, explicitly stating scope before diving into architecture demonstrates structured thinking. Interviewers often intentionally leave requirements ambiguous—clarifying scope shows you won't waste time designing the wrong system.

Key Design Challenges Preview

Now that we understand the requirements, let's preview the major technical challenges we'll solve in subsequent pages. Each challenge will receive deep treatment:

Challenge 1: Real-Time Location Tracking at Scale

The Problem: 5 million drivers each sending GPS coordinates every 4 seconds generates 1.25 million writes per second. This data must be:

Ingested without loss
Indexed spatially for fast nearby-driver queries
Expired when drivers go offline
Made available globally with low latency

Why It's Hard: Traditional databases can't handle this write volume with spatial query performance. We need specialized infrastructure.

Challenge 2: Efficient Matching at Scale

The Problem: When a rider requests a trip, we must:

Find all available drivers within ~5 km (potentially thousands)
Calculate ETA to pickup for each candidate
Score candidates on multiple factors (ETA, rating, vehicle, driver preferences)
Assign the optimal driver atomically (no double-booking)

Why It's Hard: Spatial queries, ETA calculations, and atomic assignment must complete in under 2 seconds—ideally under 1 second. The system must be globally consistent for driver assignment while allowing eventual consistency for location data.

Challenge 3: Dynamic Pricing in Real-Time

The Problem: Surge pricing must:

Reflect hyperlocal supply/demand imbalances (different pricing 1 km apart)
Update continuously (every few minutes)
Incentivize driver repositioning
Be explainable to riders

Why It's Hard: Computing optimal prices requires aggregating supply/demand across geographic cells, predicting near-term demand, and balancing multiple objectives (rider experience, driver earnings, platform revenue).

Challenge 4: Accurate ETA Calculation

The Problem: ETAs must be accurate for:

Pickup time (driver to rider)
Trip duration (origin to destination)
Surge zone validity (will demand persist?)

Why It's Hard: Traffic is dynamic and unpredictable. Road conditions change. Special events create anomalies. Historical patterns may not apply. Yet users expect accuracy within 10-20%.

Challenge 5: Reliable Trip State Management

The Problem: Trips go through complex state transitions:

REQUESTED → MATCHING → DRIVER_ASSIGNED → DRIVER_EN_ROUTE → 
DRIVER_ARRIVED → TRIP_STARTED → TRIP_COMPLETED → PAYMENT_PROCESSED

Each transition has business rules, must be durable, may trigger external systems (notifications, payment), and must handle failures gracefully.

Why It's Hard: Distributed systems can have partial failures. What happens if payment processing times out after trip completion? What if the driver's app crashes mid-trip? We need robust state machines with explicit failure handling.

What's Next

With requirements and challenges clearly defined, we're ready to dive into solutions. The next page covers Location Tracking—the foundation that enables everything else. We'll explore geospatial indexing strategies, real-time data pipelines, and the specific data structures that make sub-second driver queries possible at massive scale.

Summary: Requirements & Matching Overview

We've established a comprehensive foundation for designing a ride-sharing platform. Let's consolidate the key insights:

Key Takeaways

•Ride-sharing is a two-sided marketplace — Balancing supply (drivers) and demand (riders) in real-time is the core business challenge that drives technical decisions.
•Scale is extreme — 25 million trips/day, 1.25 million location updates/second, 99.99% availability requirements. Design must accommodate these numbers from the start.
•Matching is an optimization problem — Simple 'nearest driver' fails; production systems use ETA-based scoring, batch optimization, and ML-driven dispatch.
•Different consistency requirements — Driver assignment needs strong consistency; location data can be eventually consistent; payment must be exactly-once.
•The flash crowd problem — Systems must handle sudden, localized load spikes (concerts, sports events) without degradation.
•Scope matters — Clearly defining what's in and out of scope prevents over-engineering and focuses design effort.

Module Roadmap
Page	Topic	Key Learning
Page 1	Requirements & Matching (This Page)	Functional/non-functional requirements, scale estimation, matching problem framing
Page 2	Location Tracking	Geospatial indexing, real-time location ingestion, spatial queries at scale
Page 3	Matching Algorithm	Dispatch optimization, batch matching, driver scoring and assignment
Page 4	Surge Pricing	Supply/demand computation, pricing algorithms, market dynamics
Page 5	ETA Calculation	Route estimation, traffic prediction, accuracy optimization
Page 6	Trip Management	State machine design, payment orchestration, failure handling

Page Complete

You now have a comprehensive understanding of the requirements for a ride-sharing platform. You can articulate the functional needs of riders and drivers, specify non-functional requirements with concrete numbers, and appreciate the complexity of the matching problem. Next, we'll dive into Location Tracking—the real-time foundation that makes ride-sharing possible.