System Design Problem Breakdown: Designing Uber

Introduction

• Second system design problem breakdown video.
• Positive reception to the first video (Ticket Master).
• Future videos planned every two weeks.
• Focus on design of Uber as a common interview question.
• Presenter: Former staff engineer at Meta, co-founder of Hello Interview.

Roadmap for the Presentation

1. Requirements of the System
   • Functional Requirements: Features of the system.
   • Non-Functional Requirements: Qualities of the system.
2. Core Entities in the API
   • Objects exchanged and persisted in the system.
3. High-Level Design
   • Satisfy core functional requirements.
4. Deep Dives
   • Ensure the system meets non-functional requirements.

Functional Requirements

• Users should be able to input:
  • Start location and destination to get an estimated fare (e.g., Uber X).
  • Request a ride and be matched with a nearby driver in real-time.
  • Drivers can accept/deny requests and navigate to user locations.
• Out of scope considerations:
  • Multiple car types, ratings for drivers/riders, scheduling rides in advance.

Non-Functional Requirements

• Important to identify unique qualities for Uber:
  • Low Latency Matching: < 1 minute to match a driver.
  • Consistency: One ride matches only one driver.
  • Availability: High availability outside of matching (24/7 processing).
  • High Throughput: Handle surges during peak times (e.g., events).

Core Entities in the System

1. Ride
2. Driver
3. Rider
4. Location
   • Responsible for maintaining drivers' current locations.

API Design

• Get Fare Estimate:
  • API request to get ETA and price.
  • POST request with source and destination.
• Request Ride:
  • PATCH request to update ride status; asynchronous operation.
• Driver Accept/Deny Request:
  • PATCH request to update ride status.
• Update Driver Location:
  • Drivers periodically update their location.

High-Level Design

• Client Side:
  • Writer (Uber user) and Driver clients (mobile apps).
• API Gateway:
  • AWS API Gateway for load balancing and routing requests.
• Ride Service:
  • Handles fare estimates, uses third-party mapping API for calculations.
• Ride Matching Service:
  • Matches riders with nearby drivers, uses the location DB.
• Notification Service:
  • Sends notifications to drivers for ride requests.

Deep Dives

• Low Latency Matching:
  • Need efficient querying for driver locations.
  • Use of geospatial indexing (quad trees vs. geohashing) in databases.
• Consistency of Matching:
  • Ensure no double booking of drivers.
  • Use distributed locks (Redis) or timestamps in the database to maintain state.
• Handling High Throughput Surges:
  • Introduce a queue for incoming ride requests to balance load during peak times.

Conclusion

• Mid-level candidates should be comfortable with the high-level design and answering questions about deep dives.
• Senior candidates expected to go deeper into specific areas.
• Staff candidates should demonstrate significant depth in multiple areas.
• Engagement encouraged through comments for questions and feedback.