Bird
Raised Fist0

Uber - Driver Matching, Surge Pricing, Real-Time Location Tracking

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design Uber - Driver Matching, Surge Pricing, Real-Time Location Tracking
45 min · senior
senior

Design a backend system for a ride-hailing platform with 50 million daily active users (DAU). The system must match drivers to passengers efficiently, calculate surge pricing dynamically based on supply-demand imbalance, and track driver locations in real-time with low latency. The system should handle peak loads of up to 1 million concurrent rides and ensure P99 latency under 200ms for matching and pricing decisions. Data privacy requires end-to-end encryption of location data in transit and at rest. Offline mode support is needed for drivers with intermittent connectivity.

Constraints
  • P99 latency for driver-passenger matching and surge pricing must be under 200ms
  • End-to-end encryption of location data in transit and at rest
  • Support for offline driver location updates with eventual consistency
  • Handle peak load of 1 million concurrent rides and 50M DAU
  • Surge pricing must update dynamically every 30 seconds based on real-time supply-demand metrics
📋
Guided Steps
1/5
Step 1
Designing Real-Time Location Tracking
How would you design the system to ingest and process real-time driver location updates at scale with encryption and low latency?
💡 Hint
Consider a high-throughput, low-latency streaming platform with encryption support and TTL-based presence detection.
Key Decision
Use Apache Kafka with TLS encryption for ingesting location updates, combined with Redis Streams for low-latency presence detection and Redis TTL keys to track driver online status.
Interviewer Expectation
Mid-level: Names Kafka and Redis for streaming and caching. Senior: Explains Kafka partitioning by driver_id for ordered updates, TLS for encryption, and Redis TTL expiration for offline detection.
⚠️Common Wrong Answer
Using HTTP polling for location updates - leads to massive reconnect storms and high latency at 50M DAU.
Step 2
Driver-Passenger Matching Algorithm
How would you architect the driver-passenger matching service to meet P99 < 200ms latency under peak load?
💡 Hint
Think about spatial indexing, partitioning by geography, and asynchronous matching pipelines.
Key Decision
Use Apache Cassandra with geohash-based partition keys for driver location storage, combined with a real-time matching engine using Redis Geospatial indexes and Apache Flink for stream processing of ride requests.
Interviewer Expectation
Mid-level: Mentions Cassandra for storage and Redis for geospatial queries. Senior: Details geohash partitioning to localize queries, Flink for real-time stream processing, and fallback strategies for cold start drivers.
⚠️Common Wrong Answer
Using a single monolithic database for all location queries - causes hotspots and high latency under load.
Step 3
Surge Pricing Calculation
How would you design the surge pricing component to dynamically adjust prices every 30 seconds based on supply-demand imbalance?
💡 Hint
Consider streaming analytics and a distributed key-value store for fast read/write of pricing data.
Key Decision
Use Apache Kafka for ingesting supply-demand metrics, Apache Flink for real-time analytics and surge calculation, and store surge multipliers in Redis Cluster for low-latency reads by clients.
Interviewer Expectation
Mid-level: Names Kafka and Redis for streaming and caching. Senior: Explains Flink windowed aggregations for 30-second intervals, Kafka topic partitioning by city, and Redis Cluster sharding for scalability.
⚠️Common Wrong Answer
Calculating surge pricing synchronously on each request - causes high latency and poor scalability.
Step 4
Handling Offline Drivers and Eventual Consistency
How would you handle drivers with intermittent connectivity to ensure their location and availability are eventually consistent?
💡 Hint
Think about local buffering on client, conflict resolution, and TTL-based presence expiration.
Key Decision
Implement local buffering of location updates on driver app with exponential backoff retries, use Kafka for durable ingestion, and Redis TTL keys to mark offline drivers after heartbeat expiry.
Interviewer Expectation
Mid-level: Mentions retry logic and TTL keys. Senior: Details client-side buffering strategies, Kafka exactly-once semantics for ingestion, and Redis TTL expiration triggering offline workflows.
⚠️Common Wrong Answer
Dropping location updates during offline periods - leads to stale driver availability and poor matching.
Step 5
API Design for Core Interactions
Sketch the APIs for driver location update, passenger ride request, and surge price query. What are the key considerations for each?
💡 Hint
Focus on request payload, authentication, idempotency, and response latency.
Key Decision
Design RESTful endpoints with JWT authentication; driver location update uses batched protobuf payloads over HTTPS with idempotency keys; ride request API supports async callbacks/webhooks; surge price query uses HTTP GET with caching headers.
Interviewer Expectation
Mid-level: Defines basic REST endpoints with auth. Senior: Explains protobuf for payload efficiency, idempotency to handle retries, async ride request flow, and cache-control for surge price queries.
⚠️Common Wrong Answer
Using synchronous blocking calls for ride requests - increases latency and reduces throughput.
🔌
API Design Challenge
Sketch 3 core API endpoints for the system: driver location update, passenger ride request, and surge price query.
Hints
  • How does the driver send location updates efficiently and securely?
  • How does the passenger request a ride and receive a matched driver?
  • How does the client query surge pricing and handle dynamic updates?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of Kafka with TLS for encrypted, ordered, and scalable location ingestion
  • Geohash-based partitioning in Cassandra for scalable spatial queries
  • Real-time stream processing with Apache Flink for surge pricing and matching
  • Redis TTL keys for offline driver detection and presence management
Good to Have - 30%
  • Client-side buffering and retry logic for offline driver updates
  • Redis Geospatial indexes for efficient nearest driver lookup
  • Async ride request API design with idempotency and callbacks
Bonus - 10%
  • Detailed explanation of failure modes under load and mitigation strategies
  • Discussion of trade-offs between consistency and latency in location updates
Anti-patterns to Avoid
Using HTTP polling for location updates causes massive reconnect storms at 50M DAU, resulting in 50 million reconnects per minute just to check for messages, which collapses the system under load.
Using a single monolithic database for all location queries creates hotspots and high latency under load, severely degrading system performance and scalability.
Calculating surge pricing synchronously on each request leads to high latency and poor scalability, causing delays in pricing updates and degraded user experience.
✅
Model Answer
▼ Reveal

This design leverages scalable, distributed streaming and storage technologies to handle Uber's core backend challenges: real-time driver location tracking, efficient driver-passenger matching, and dynamic surge pricing. It ensures low latency, high throughput, and data privacy with encryption and offline support.

Key Decisions
  • Use Apache Kafka with TLS encryption to ingest high-throughput driver location streams, partitioned by driver_id to maintain ordering.
  • Store driver locations in Apache Cassandra using geohash-based partition keys to localize queries and scale horizontally.
  • Use Redis Geospatial indexes for fast nearest-driver lookups in the matching engine.
  • Process ride requests and surge pricing calculations in real-time using Apache Flink with windowed aggregations every 30 seconds.
  • Store surge multipliers in Redis Cluster to provide low-latency, scalable access for clients.
  • Implement client-side buffering with exponential backoff and Kafka exactly-once semantics to handle offline driver updates reliably.
  • Design RESTful APIs with JWT authentication; use protobuf for efficient payloads; ensure idempotency keys for retries; support async callbacks/webhooks for ride requests; and use cache-control headers for surge price queries.
  • Apache Kafka with TLS encryption for ingesting high-throughput driver location streams
  • Redis Streams and TTL keys for low-latency presence detection and offline driver tracking
  • Apache Cassandra with geohash partition keys for scalable driver location storage and queries
  • Redis Geospatial indexes for fast nearest-driver lookups in matching engine
  • Apache Flink for real-time stream processing of ride requests and surge pricing calculations
  • Redis Cluster for storing surge multipliers with low-latency access and horizontal scalability
  • Client-side buffering with exponential backoff and Kafka exactly-once semantics for offline driver updates
  • RESTful APIs with protobuf payloads, JWT authentication, idempotency keys, and async callbacks for ride requests

Practice

(1/5)
1. A mobile app requires tailored API responses per device type to reduce payload size and improve UX. Which component best handles this requirement in a microservices architecture?
easy
A. Use a shared database view that filters data per device type
B. Use a CDN to cache different payloads per device type
C. Let each microservice handle device-specific logic internally
D. Implement a Backend-for-Frontend (BFF) layer that adapts responses per client

Solution

  1. Step 1: Identify the role of BFF

    The BFF layer acts as a tailored API gateway that adapts responses specifically for each client type, reducing payload and improving UX.

  2. Step 2: Eliminate other options

    Use a shared database view that filters data per device type is incorrect because database views are not designed for client-specific adaptation and increase coupling. Let each microservice handle device-specific logic internally is wrong as microservices should remain generic and not handle client-specific logic. Use a CDN to cache different payloads per device type is incorrect because CDNs cache static content and cannot dynamically tailor API responses per device.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    BFF adapts APIs per client type for optimized payloads [check]
Hint: BFF adapts APIs per client type for optimized payloads [check]
Common Mistakes:
2. In a system where Step 4 is the Delivery Worker checking message delivery status, what happens if the Delivery Worker finds the recipient's presence TTL expired?
easy
A. The Delivery Worker queues the message for offline delivery and updates status to 'sent but not delivered'
B. The Delivery Worker immediately marks the message as delivered without retry
C. The Delivery Worker deletes the message assuming recipient is unreachable
D. The Delivery Worker retries sending indefinitely until TTL is refreshed

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- Bob's presence TTL

    If TTL expired, recipient is offline; message can't be delivered immediately.

  2. Step 2: Understand offline delivery handling

    Delivery Worker queues message for later delivery and marks status as 'sent but not delivered' to reflect state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL -> queue message, status 'sent but not delivered' [check]
Hint: Expired TTL means offline, queue message for later delivery [check]
Common Mistakes:
3. In a microservices architecture, a client request flows through API Gateway -> Auth Service -> Order Service -> Inventory Service. At step 3, the Order Service calls Inventory Service synchronously. What happens if Inventory Service is slow at step 3?
easy
A. Auth Service caches Inventory Service response to speed up future calls
B. Order Service queues the request asynchronously and immediately returns success to client
C. API Gateway retries the Inventory Service call automatically without client awareness
D. Order Service blocks the client request until Inventory Service responds or times out

Solution

  1. Step 1: Trace synchronous call behavior at step 3

    Order Service calls Inventory Service synchronously, so it waits for response before replying to client.

  2. Step 2: Analyze impact of slow Inventory Service

    Because of synchronous call, client request blocks until Inventory Service responds or times out; no immediate return or retries happen automatically.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous calls block caller until response or timeout [check]
Hint: Synchronous calls block caller until response or timeout [check]
Common Mistakes:
4. Without a properly chosen partition key in Cassandra, what exact failure occurs when querying a large dataset?
medium
A. Queries return stale data due to eventual consistency delays
B. Data is duplicated across multiple partitions causing inconsistency
C. Writes fail silently without error messages
D. Queries time out or fail due to coordinator node overload from large partitions

Solution

  1. Step 1: Understand impact of partition key on data distribution

    Improper partition keys cause very large partitions, leading to coordinator overload during queries.

  2. Step 2: Trace failure mode

    Large partitions cause coordinator to timeout or fail when scanning data; stale data and silent write failures are unrelated; data duplication is controlled by replication, not partition key choice.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Large partitions -> coordinator overload -> query timeouts [check]
Hint: Large partitions overload coordinator -> query timeouts [check]
Common Mistakes:
5. At 10x scale, which component in a multi-tier storage system is most likely to become the bottleneck first, and why?
hard
A. Archive storage because tape drives have limited concurrent access bandwidth
B. Metadata service because it maintains global access frequency and tiering decisions, causing high coordination overhead
C. Cold storage because object storage scales linearly with data size
D. Warm storage because HDDs have slower seek times but can be scaled horizontally easily

Solution

  1. Step 1: Identify component roles at scale

    Archive storage uses tape drives with limited concurrent access bandwidth and high latency.

  2. Step 2: Analyze scaling challenges

    At 10x scale, tape drives become bottleneck due to limited parallelism and slow seek times, unlike metadata which can be sharded.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Archive tape bandwidth limits -> first bottleneck [check]
Hint: Tape archive bandwidth limits scale poorly [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard