Design a Real-Time Nearby-Driver Service

Quick Overview

Design a real-time service that finds available drivers near a passenger as locations update every few seconds. Cover spatial partitioning, cell boundaries, hot spots, stale-driver expiry, state transitions, exact filtering, client smoothing, and failure recovery.

Design a Real-Time Nearby-Driver Service

Company: Uber

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a real-time proximity service that returns available drivers near a passenger's current location. Drivers move continuously and report a new location about every four seconds. Query density varies sharply between dense city centers and suburbs. Results must respect a search radius and driver state, and should not make vehicles appear to jump erratically on the client. ### Constraints & Assumptions - Current location and availability are latency-sensitive; historical trajectories have a different durability requirement. - Most searches are local to one city, so cross-city queries are exceptional. - The design may use a grid, quadtree, geohash, S2 cells, or another spatial index, but must explain boundary handling. - Exact capacity and QPS figures should be derived from clarified driver counts and update rates rather than assumed. ### Clarifying Questions to Ask - How many drivers are online per city, and what update loss or staleness is acceptable? - Is the query a fixed radius, nearest `k`, or both, and how many candidates may be returned? - Must distance mean straight-line distance, estimated travel time, or an exact route-service result? - How quickly must an accepted trip remove a driver from search results? ```hint Make the cell size part of the design A cell that is too large produces too many candidates; one that is too small increases the number of neighboring cells each query must inspect. ``` ### What a Strong Answer Covers - A partitioning and spatial-index strategy, including neighboring-cell lookup and uneven-density hot spots. - A high-write current-location store separated from asynchronous historical trajectory storage. - Update ingestion, stale-driver expiry, availability transitions, deduplication, and city-level routing. - Candidate retrieval, exact filtering, optional route-distance refinement, client smoothing, scaling, and failure recovery. ### Follow-up Questions - How would you handle two nearby drivers that fall on opposite sides of a geohash boundary? - What happens when a downtown cell becomes far hotter than neighboring cells? - How would you prevent an already matched driver from briefly reappearing because a location update arrived late?

Quick Answer: Design a real-time service that finds available drivers near a passenger as locations update every few seconds. Cover spatial partitioning, cell boundaries, hot spots, stale-driver expiry, state transitions, exact filtering, client smoothing, and failure recovery.

|Home/System Design/Uber
Uber logo
Uber
Aug 16, 2026, 12:00 AM
mediumSoftware EngineerOnsiteSystem Design
0
0

Design a real-time proximity service that returns available drivers near a passenger's current location.

Drivers move continuously and report a new location about every four seconds. Query density varies sharply between dense city centers and suburbs. Results must respect a search radius and driver state, and should not make vehicles appear to jump erratically on the client.

Constraints & Assumptions

  • Current location and availability are latency-sensitive; historical trajectories have a different durability requirement.
  • Most searches are local to one city, so cross-city queries are exceptional.
  • The design may use a grid, quadtree, geohash, S2 cells, or another spatial index, but must explain boundary handling.
  • Exact capacity and QPS figures should be derived from clarified driver counts and update rates rather than assumed.

Clarifying Questions to Ask Guidance

  • How many drivers are online per city, and what update loss or staleness is acceptable?
  • Is the query a fixed radius, nearest k , or both, and how many candidates may be returned?
  • Must distance mean straight-line distance, estimated travel time, or an exact route-service result?
  • How quickly must an accepted trip remove a driver from search results?

What a Strong Answer Covers Guidance

  • A partitioning and spatial-index strategy, including neighboring-cell lookup and uneven-density hot spots.
  • A high-write current-location store separated from asynchronous historical trajectory storage.
  • Update ingestion, stale-driver expiry, availability transitions, deduplication, and city-level routing.
  • Candidate retrieval, exact filtering, optional route-distance refinement, client smoothing, scaling, and failure recovery.

Follow-up Questions Guidance

  • How would you handle two nearby drivers that fall on opposite sides of a geohash boundary?
  • What happens when a downtown cell becomes far hotter than neighboring cells?
  • How would you prevent an already matched driver from briefly reappearing because a location update arrived late?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...