Question 1

How do you implement geospatial driver search — Redis GEOSEARCH vs PostGIS?

Accepted Answer

Redis GEOSEARCH (backed by a sorted set with Geohash scores) gives sub-millisecond radius queries and horizontal scalability, making it the right choice for the hot path: find all available drivers within N km of a rider in real time. Driver locations are written to Redis on every GPS heartbeat (every 4 s). PostGIS stores the authoritative location history and is used for analytics, surge-zone polygons, and auditing — not for the matching critical path. A common pattern is a write-through cache: each driver heartbeat updates both Redis (for live search) and Postgres/PostGIS (for persistence). For very dense cities a Geohash prefix index in Redis partitions the keyspace further, so GEOSEARCH scans a smaller sorted set. PostGIS shines when the query involves arbitrary polygon containment (e.g., 'is this driver inside surge zone 42?') because ST_Within on a spatial index is fast for complex shapes that a bounding-circle in Redis would over-include.

Question 2

How is surge pricing calculated and smoothed to avoid sudden multiplier jumps?

Accepted Answer

Surge is fundamentally a supply/demand ratio computed per geohash cell. A background job (runs every 30-60 s) counts active riders requesting in each cell versus available drivers. The raw ratio feeds a piecewise linear or logistic function capped at a business-defined maximum (e.g., 5x). To prevent the multiplier from spiking and dropping chaotically, two smoothing techniques are applied: (1) Temporal smoothing — an exponential moving average blends the new ratio with the previous value (alpha ~0.3), so a single-minute spike doesn't cause a full surge. (2) Spatial smoothing — neighboring cells' values are averaged with a Gaussian kernel so there are no hard cliff edges at cell boundaries. The resulting multiplier is rounded to the nearest 0.1x and shown to the rider before booking. A surge-lock window (e.g., 2 minutes) holds the multiplier constant after a rider sees the estimate, preventing bait-and-switch during payment.

Question 3

How do you compute accurate ETAs for pickup vs final destination?

Accepted Answer

Pickup ETA (driver to rider) uses real-time traffic data (Google Maps Platform / HERE / in-house routing graph with live speed data), the driver's current GPS position, and road-network shortest-path (Dijkstra or A* on a precomputed contraction hierarchy). Because GPS updates arrive every 4 s, ETA is recalculated on each heartbeat and pushed to the rider. Destination ETA (rider to drop-off) is computed at booking time from the pickup point using historical travel-time distributions for that corridor and time-of-day, giving a p50 and p90 estimate. The two ETAs use different data freshness requirements: pickup ETA must reflect the last known driver position, while destination ETA can tolerate a 1-minute-stale routing graph. A separate ML model trained on completed trips corrects systematic bias (e.g., Friday 5 pm on a specific highway corridor always runs 15% over the routing engine's estimate).

Question 4

How does the driver-passenger matching offer and timeout mechanism work?

Accepted Answer

The matching service runs a batched optimization every 5-15 s (or event-triggered on new requests). It scores each (driver, rider) pair on weighted factors: ETA, acceptance rate, driver rating, and in some markets preferred driver lists. The top candidate receives an exclusive offer pushed via WebSocket/long-poll to the driver app. The offer carries a TTL (typically 15 s). If the driver accepts, the trip is locked and a confirmation event is published. If the driver rejects or the TTL expires, the system marks that driver unavailable for this request for a backoff window (to prevent re-offering immediately) and re-runs the match for the next candidate. To prevent starvation, if a request ages beyond a threshold (e.g., 90 s without a match), the search radius expands in concentric rings. All state transitions are stored in an event log (Kafka topic) so the dispatch team can replay and audit why a particular match was or wasn't made.

Question 5

What does the trip state machine look like and how is event sourcing applied?

Accepted Answer

A trip progresses through: REQUESTED → MATCHED → DRIVER_EN_ROUTE → ARRIVED → IN_PROGRESS → COMPLETED (or CANCELLED from most states). Each transition is triggered by an explicit event (DriverAccepted, DriverArrived, TripStarted, TripEnded, CancelledByRider, etc.) published to a Kafka topic. The current state is derived by replaying the event log — the database stores events, not mutable state rows. This means: (1) full audit trail for disputes, (2) easy replay for debugging, (3) projections (read models) can be rebuilt at any time. A separate trip-state service consumes the Kafka topic and maintains a materialized view (Redis or Postgres) of current trip status for low-latency reads. Idempotency keys on each event prevent double-processing if a producer retries. Compensation events handle edge cases like a driver marking arrival twice — the second ArrivedEvent is a no-op because the state machine only accepts that transition from DRIVER_EN_ROUTE.

Low Level Design: Ride-Sharing Service

Trip State Machine

Geospatial Driver Search

Driver-Passenger Matching

Surge Pricing

ETA Computation

Route and Navigation

Safety Features

Driver Rating System