Design an ETA Service and Location Sharing Between Driver and Rider — System Design Interview Practice

Interview prompt

Design a ride ETA and location-sharing service that combines route/traffic data with live driver positions, serves smooth updates to riders, and handles GPS noise, reconnects, and trip privacy.

• Define trip ownership, route/version, GPS sample quality, map matching, traffic snapshot, ETA confidence, location cadence, and visibility TTL.
• Partition by trip/region, smooth noisy or delayed positions, throttle fan-out, and keep driver/rider reads consistent enough without blocking movement.
• Separate location ingestion from ETA computation, routing-provider calls, rider WebSocket fan-out, history, and analytics.
• Explain reconnect replay, provider outage, trip cancellation, privacy, spoofing, observability, and cached/coarse ETA fallback.

Requirements and scale assumptions

• Create trips, accept authenticated driver positions, map-match them, calculate ETA from route/traffic, and share authorized live location.
• Support rider/driver reconnects, trip states, route changes, pickup/dropoff, location freshness, notifications, and trip history.
• Handle duplicate/out-of-order GPS samples, provider retries, trip deletion/retention, privacy controls, and region failover.
• Deliver fresh location updates every few seconds and serve ETA reads with p95 under 300ms when route providers are healthy.
• Scale to 5M active trips and reconnect bursts without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 5M active trips, 1M position updates per second, and 10M concurrent subscribers
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 5M trips; 1M positions/s — Capacity assumption that drives partitioning and backpressure.
• Latency target: updates every 3s; ETA p95 < 300ms — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Trip state and signed position samples are authoritative; ETA, map matches, and fan-out views are derived.
• Async boundary: At-least-once workers — Keep WebSocket for real-time location updates, Map APIs for routing and traffic, Machine learning for ETA prediction off the synchronous path.

Key entities

• InteractioninteractionId, actorId, objectId, type, version, occurredAt

  Canonical eta service and location sharing between driver and rider interaction with an idempotency key and ordering version.

• ConnectionSessionsessionId, userId, deviceId, roomKey, lastHeartbeat, status

  Ephemeral but observable eta service and location sharing between driver and rider connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for eta service and location sharing between driver and rider fan-out and replay.

• DeliveryReceiptinteractionId, recipientId, channel, attempt, status, deliveredAt

  Deduplicated eta service and location sharing between driver and rider delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe eta service and location sharing between driver and rider gateway authenticates the actor, validates room or object membership, applies rate limits, and conditionally commits the interaction.
2. 2. Publish an ordered eventAn outbox emits the committed eta service and location sharing between driver and rider transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route eta service and location sharing between driver and rider events to connected recipients, durable inboxes, or notification channels without making the origin write wait for every recipient.
4. 4. Resume and reconcile connectionsClients reconnect with a cursor; the eta service and location sharing between driver and rider service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks eta service and location sharing between driver and rider publish-to-deliver latency, hot partitions, reconnect storms, dropped events, and consumer lag for replay or repair.

Deep dives and trade-offs

• Ordering, idempotency, and hot keysChoose a eta service and location sharing between driver and rider partition key that preserves required order while distributing high-volume rooms, users, or objects. Use event IDs, inboxes, consumer offsets, and conditional state transitions for at-least-once delivery. Split or isolate hot partitions without changing the client-visible sequence contract.
• Reconnect and replay semanticsIssue resumable eta service and location sharing between driver and rider cursors with an expiry and a clear snapshot-plus-delta fallback. Bound replay windows and rebuild from durable state when a cursor is too old. Expose version and freshness so a client can distinguish current, catching up, and degraded state.
• Backpressure and presenceKeep connection heartbeats and ephemeral presence separate from durable eta service and location sharing between driver and rider interactions. Coalesce safe updates, shed low-value work, and protect critical events during reconnect storms. Measure end-to-end delivery, not only broker publish latency.
• Direct fan-out versus pull-based readsUse push for latency-sensitive eta service and location sharing between driver and rider deltas and pull or replay for reconnect, history, and recovery. A push-only design loses state when clients disconnect and a pull-only design wastes latency and bandwidth.
• Per-recipient queues versus shared streamsUse shared partitioned streams with per-recipient cursors where fan-out is large, and isolate exceptional high-fanout objects. A queue per recipient becomes expensive and hard to inspect at large scale.
• Strong ordering versus availabilityGuarantee ordering only within the scope the product needs, such as a room, object, or conversation. Global ordering introduces a bottleneck and still does not solve duplicate delivery or reconnect recovery.