Katkat
Back

Design a Driver Leaderboard Based on Reviews

UberSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This problem tests the ability to design a scalable, low-latency leaderboard system that handles high-frequency write throughput from reviews and supports read-heavy leaderboard queries.

Problem Statement

Design a service that maintains a real-time leaderboard of drivers based on their customer ratings. The system must support two primary operations: recording a new review for a driver and fetching the global top-K drivers.

Functional Requirements

  1. submit_review(driver_id, rating): A system to ingest a numerical rating (1-5 stars) for a specific driver.
  2. get_top_drivers(K): A query to retrieve the top K drivers based on their average rating.

Non-Functional Requirements

  • Scale: Assume 1 million active drivers and 10,000 reviews per second during peak hours.
  • Consistency: The leaderboard does not need to be strictly consistent in real-time, but should reflect updates within a few seconds (eventual consistency).
  • Availability: The system must be highly available for read requests.

Design Deliverables

  • API definitions for the ingestion and leaderboard services.
  • Data storage strategy: Consider the trade-offs between relational databases, NoSQL, and caching layers (e.g., Redis).
  • Architectural diagram description: How you handle the flow of data from ingestion to aggregation.
  • Strategies for handling skewed data (e.g., highly popular drivers getting thousands of reviews).

Example

  • Input: submit_review(driver_123, 5)
  • Query: get_top_drivers(3) -> [driver_55, driver_90, driver_123] (Assuming current averages).

Hints

Hint 1

Consider using an aggregation service to buffer reviews rather than updating the database on every single incoming write.

Hint 2

Redis Sorted Sets are highly efficient for maintaining top-K rankings; evaluate if they meet your memory requirements for 1 million drivers.

Hint 3

Think about the difference between a 'moving average' and a 'windowed average' and how that affects the complexity of your leaderboard updates.

Follow-up questions

  • How would you modify your design to calculate the top drivers per city instead of globally?
  • How do you handle the 'cold start' problem where a new driver has only one 5-star review?
  • If the leaderboard needs to be updated every 5 minutes instead of real-time, how would your architecture change to optimize for cost and throughput?