Lesson 1.5: Case Study - Uber's Real-Time Architecture

Uber's Challenge

Millions of concurrent users
Real-time driver-rider matching
Dynamic pricing (surge)
Trip routing and ETAs

All of this requires sub-second latency with transactional consistency.

Their Stack

Databases:

MySQL: Primary transactional database (sharded)
PostgreSQL: Analytics and ML features
Redis: Geospatial indexes for driver locations
Cassandra: Time-series data (trip logs)

The Matching Algorithm

Rider requests ride
    ↓
[Redis: Find nearby drivers (geospatial query)] (5ms)
    ↓
[MySQL: Fetch driver details, ratings, vehicle] (10ms)
    ↓
[Pricing Engine: Calculate surge multiplier] (5ms)
    ↓
[MySQL: Begin transaction]
    ├─ INSERT trip request
    ├─ UPDATE driver status
    ├─ INSERT pricing record
[MySQL: COMMIT] (15ms)
    ↓
Notify driver (push notification)

Total latency: Under 50ms from request to driver notification.

Why Not NoSQL for Everything?

Uber tried. They famously moved from PostgreSQL to MySQL in 2016 for specific technical reasons, but they kept SQL databases because:

Transactions matter: Can't double-book drivers
Complex queries: Joining trip data with driver data with pricing
Consistency: Surge pricing must be atomic
Compliance: Financial audits require ACID guarantees

The Geospatial Problem

Challenge: Find all drivers within 2km of rider, in under 10ms.

Why not SQL?

-- This query is SLOW (full table scan)
SELECT * FROM drivers
WHERE ST_Distance(location, rider_location) < 2000
    AND status = 'available';

Solution: Redis with geospatial indexes

GEOADD drivers longitude latitude driver_id
GEORADIUS rider_lng rider_lat 2 km WITHDIST

Then: Use SQL to fetch driver details

-- Fast: using primary key IN clause
SELECT * FROM drivers
WHERE driver_id IN (results_from_redis);

Lesson: Use the right tool for each job. Redis for geo, SQL for everything else.

Key Takeaways

Uber handles millions of concurrent users with SQL databases (MySQL + PostgreSQL)
Real-time matching requires sub-second latency with ACID transactions
Hybrid architecture: Redis for geospatial, SQL for transactional data
NoSQL couldn't replace SQL because transactions and consistency are critical
Using the right tool for each specific job creates optimal performance

The Matching Algorithm

Rider requests ride ↓ [Redis: Find nearby drivers (geospatial query)] (5ms) ↓ [MySQL: Fetch driver details, ratings, vehicle] (10ms) ↓ [Pricing Engine: Calculate surge multiplier] (5ms) ↓ [MySQL: Begin transaction] ├─ INSERT trip request ├─ UPDATE driver status ├─ INSERT pricing record [MySQL: COMMIT] (15ms) ↓ Notify driver (push notification)

Total latency: Under 50ms from request to driver notification.

Why Not NoSQL for Everything?

Uber tried. They famously moved from PostgreSQL to MySQL in 2016 for specific technical reasons, but they kept SQL databases because:

Transactions matter: Can't double-book drivers

Complex queries: Joining trip data with driver data with pricing

Consistency: Surge pricing must be atomic

Compliance: Financial audits require ACID guarantees

The Geospatial Problem

Challenge: Find all drivers within 2km of rider, in under 10ms.

Why not SQL?

-- This query is SLOW (full table scan) SELECT * FROM drivers WHERE ST_Distance(location, rider_location) < 2000 AND status = 'available';

Solution: Redis with geospatial indexes

GEOADD drivers longitude latitude driver_id GEORADIUS rider_lng rider_lat 2 km WITHDIST

Then: Use SQL to fetch driver details

-- Fast: using primary key IN clause SELECT * FROM drivers WHERE driver_id IN (results_from_redis);

Lesson: Use the right tool for each job. Redis for geo, SQL for everything else.

Key Takeaways

Uber handles millions of concurrent users with SQL databases (MySQL + PostgreSQL)

Real-time matching requires sub-second latency with ACID transactions

Hybrid architecture: Redis for geospatial, SQL for transactional data

NoSQL couldn't replace SQL because transactions and consistency are critical

Using the right tool for each specific job creates optimal performance