System Design: Uber (High Level)

 

1️⃣ What is Uber solving?

Uber is a real-time ride-hailing system that:

• Matches riders with nearby drivers

• Tracks live location

• Calculates fare

• Handles payments

Key challenge: Real-time, geo-based matching at massive scale

---

2️⃣ Core Requirements (Interview Language)

Functional

• Request a ride

• Match rider with nearest driver

• Track driver in real time

• Calculate fare

• Process payment

Non-Functional

• Low latency (real-time)

• High availability

• Scalability (millions of users)

• Fault tolerance

---

3️⃣ High-Level Architecture

Clients

• Rider Mobile App

• Driver Mobile App

Backend Services

• API Gateway

• User Service (riders & drivers)

• Location Service

• Matching Service

• Pricing Service

• Trip Service

• Payment Service

• Notification Service

---

4️⃣ Key Design Concepts (Very Important)

🔹 Location Tracking

• GPS updates sent every few seconds

• Stored in in-memory stores (Redis)

• Use GeoHash / QuadTree

🔹 Matching

• Find nearest available driver

• Geo-based indexing

• Short-range search → expand radius

🔹 Real-Time Updates

• WebSockets / Long polling

• Push driver location updates to rider

🔹 Data Storage

• Redis → real-time locations

• SQL / NoSQL → trips, users

• Kafka → event streaming (trip events)

---

5️⃣ Typical Interview Flow (How You Say It)

“Uber is a real-time, geo-distributed system.
Riders send ride requests, drivers continuously publish location updates.
A matching service uses geo-spatial indexing to find the nearest driver.
Redis is used for fast location lookup, and Kafka handles trip events.”

---

6️⃣ Common Interview Follow-ups

• How do you avoid two riders getting same driver? → Distributed locking

• How do you scale location updates? → Partition by geo-region

• How do you handle surge pricing? → Dynamic pricing service