System Design of Uber - Lecture Notes

Introduction

• Speaker: Anshul Sadariya, Software Engineer 3 at Google
• Topic: System design of Uber and similar cab service applications (Ola, Lyft, Kareem)
• Previous Work: System designs for Twitter, Tinder
• Purpose: Understand how large-scale products work

User Journeys (CUJs)

Drivers

1. Create Profile
2. Show Availability
3. Accept or Reject Ride
   • Upon rejection, repeat the flow
4. Navigate to Pickup Location
5. Start the Ride (post-OTP or authentication)
6. Navigate to Drop Location
7. End the Ride and Accept Payment
8. Optionally Rate Rider

Riders

1. Create Profile
2. Show Nearby Cabs based on user location
3. Add Start and End Locations
4. Show Estimated Time of Arrival (ETA) and Approximate Price
5. Book Cab
6. Make Payment and Optionally Rate Driver
7. View Past Trips and Payment History
8. Check Current Trip Status

Functional and Non-Functional Requirements

Functional Requirements

• Profile creation, availability, and location services for drivers and riders
• Trip initiation, navigation, and termination
• Payment processing
• Rating system
• Viewing trip history and current trip status

Non-Functional Requirements

• Minimal Latency: Essential for various user journeys but with tolerable delays for non-critical operations
• High Availability: 24/7 availability, crucial for continuous operation in major and minor cities globally
• Durability: Persistent data storage for trip records, payment histories
• Scalability: Capability to handle peak and non-peak times, expand to new regions
• Consistency: Balance between high availability and strong consistency for different services

Application Scale

• Monthly Active Users (MAUs): 100 million
• Daily Rides: 10 million
• Active Drivers per Day: 1 million
• Request/Booking Rate: 100 QPS (Queries Per Second)

Communication

HTTP Requests

• Synchronous communication
• Request-response mechanism

WebSocket Servers

• Asynchronous communication
• Peer-to-peer connection
• Continual location pings from drivers

Finding Nearby Cabs

Location Data Storage

• Store driver locations in a database with fast retrieval
• Use primary indexing on latitude or longitude for optimization

Two-Dimensional to One-Dimensional Transformation

• Techniques: Geohash, Quad Trees, Google S2 Library
• Google S2 Library: Divides spherical globe into chunks, each chunk given an ID

Core Services

Map Service

• Converts latitude-longitude to chunk ID
• Computes ETA and distance
• Integrates with payment service for price estimation

Location Service

• Stores latest and historical location data
• Uses a Redis cluster for latest data, Cassandra for historical data

Cab Finder Service

• Matches user requests with available drivers
• Uses consistent hashing for service distribution
• Employs gossip protocol for server updates

Trip Service

• Manages active and inactive trips
• Stores active trips in SQL, inactive in Cassandra
• Trip Archiver to move completed trips to Cassandra

Payment Service

• Calculates trip fare based on distance and time
• Integrates with payment gateways like Stripe, RazorPay

Profile Service

• CRUD operations for user profiles
• Rating functionality

Additional Concepts

• Preferred Access Points: Identified using aggregation of trip start/end locations
• Fraud Detection: Machine learning used to detect fraudulent activities by drivers
• Machine Learning Integrations: Price surging, traffic analysis
• Logging and Monitoring: Log analysis and visualization using ELK stack (Elasticsearch, Logstash, Kibana)

Summary

• Discussed key services and their responsibilities
• Explored functional and non-functional requirements
• Mentioned potential scale and technical challenges
• Brief on payment and trip management services
• Covered essential and additional technical concepts for a large-scale Uber-like application

Call to Action

• Check Scalar's free master classes
• Like, comment, and subscribe to Scalar's YouTube channel