A ride-sharing platform (Uber, Lyft) matches riders with nearby drivers in real time, handles surge pricing, tracks vehicle positions, and manages the full trip lifecycle. The core engineering challenges are: efficient geo-spatial driver location queries, low-latency matching at scale, and real-time communication between rider, driver, and backend.
Driver Location Tracking
Active drivers send GPS updates every 4 seconds. At 100,000 active drivers, this is 25,000 location updates/second. Storage: Redis geospatial index (GEOADD, GEORADIUS). Each driver update: GEOADD drivers {longitude} {latitude} {driver_id}. To find nearby drivers: GEORADIUS drivers {rider_lng} {rider_lat} 2km ASC COUNT 10 — returns the 10 closest drivers within 2km, sorted by distance. Redis geospatial commands use a geohash internally — O(log n + k) per radius query. At 100k drivers, this is sub-millisecond. Location history (for trip replay, dispute resolution) is written to a time-series store (Kafka → Cassandra) asynchronously.
Matching Algorithm
When a rider requests a trip: (1) Find candidate drivers within radius using GEORADIUS. (2) Filter: only drivers with status=available (not already matched). (3) Score candidates: eta_to_rider (shortest is best), rating, vehicle type match. (4) Offer the trip to the top candidate — send a push notification to the driver’s device. (5) If the driver accepts within 15 seconds, the trip is matched. If the driver declines or doesn’t respond, move to the next candidate. This sequential offer approach (offer one driver at a time) prevents the same ride from being offered to multiple drivers simultaneously. Some systems broadcast to the top-k drivers and accept the first to confirm — faster but requires deduplication.
Trip State Machine
Each trip transitions through states: REQUESTED → DRIVER_ASSIGNED → DRIVER_EN_ROUTE → ARRIVED_AT_PICKUP → IN_PROGRESS → COMPLETED | CANCELLED. State transitions are recorded with timestamps — enabling ride receipts, analytics, and dispute resolution. Each transition is an event in a Kafka topic, consumed by: the billing service (start billing at IN_PROGRESS), the notification service (send “driver arriving” push at ARRIVED_AT_PICKUP), and the analytics pipeline. State is stored in a database (PostgreSQL); the current state per trip is cached in Redis for low-latency status checks by the rider and driver apps.
Surge Pricing
Surge pricing dynamically increases fares when demand exceeds supply in a geographic area. Implementation: divide the city into hexagonal cells (H3 geospatial indexing at resolution 7 — ~0.5km² per cell). For each cell, compute the demand/supply ratio: active_ride_requests / available_drivers_within_reach. If ratio > threshold, apply a surge multiplier. The surge multiplier is computed every 30-60 seconds for each cell. Riders see the surge before confirming — “1.8x surge pricing applies.” This is a demand-side signal that both increases supply (higher earnings attract more drivers) and reduces demand (some riders cancel or wait).
Real-Time Communication
Rider and driver apps need real-time updates: driver location on the rider’s map, arrival notification, trip status changes. Architecture: each app maintains a WebSocket connection to a presence server. Driver location updates are published to a Kafka topic (driver.locations); a location fanout service consumes and pushes to the rider’s WebSocket (the rider watching that driver). Trip status events are published to a Kafka topic (trips.events); event consumers push to both rider and driver WebSockets. The presence layer routes messages based on rider_id and driver_id → WebSocket connection mapping, stored in Redis (user_id → server_id for the server holding the WebSocket connection).
See also: Meta Interview Guide 2026: Facebook, Instagram, WhatsApp Engineering
See also: Uber Interview Guide 2026: Dispatch Systems, Geospatial Algorithms, and Marketplace Engineering
See also: Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering
See also: Airbnb Interview Guide 2026: Search Systems, Trust and Safety, and Full-Stack Engineering
See also: Databricks Interview Guide 2026: Spark Internals, Delta Lake, and Lakehouse Architecture
See also: Anthropic Interview Guide 2026: Process, Questions, and AI Safety
See also: Atlassian Interview Guide
See also: Coinbase Interview Guide
See also: Shopify Interview Guide
See also: Snap Interview Guide
See also: Lyft Interview Guide 2026: Rideshare Engineering, Real-Time Dispatch, and Safety Systems
See also: Stripe Interview Guide 2026: Process, Bug Bash Round, and Payment Systems