Katkat
Back

Design Real-Time Vehicle Location Tracking

ZooxBackend Engineer · Technical Screen
MediumBackend EngineerTechnical ScreenSystem Design

Last updated

Design a high-throughput, low-latency telemetry ingestion and distribution system that streams autonomous vehicle coordinates to client dashboards and rider apps.

Scenario

Zoox operates a fleet of autonomous robotaxis in dense urban environments. Each vehicle continuously broadcasts its GPS coordinates, speed, heading, and status. Dispatchers in fleet operations require an interactive, sub-second live map of the entire operating domain, while end-user passenger apps need live tracking of their specific assigned vehicle. Design the real-time vehicle location tracking backend.

Requirements

Functional Requirements

  • Telemetry Ingestion: Ingest frequent location pings (latitude, longitude, heading, speed, vehicle ID, timestamp, operational status) from vehicles.
  • Real-Time Client Streaming: Push location updates to authorized consumers:
    • Dispatchers / Fleet Ops: View all active vehicles within a dynamic bounding box / viewport.
    • Riders: View the exact location of their dispatched vehicle.
  • Historical Playback: Support historical queries to inspect a vehicle's path over a specific time range (e.g., incident review).
  • Access Control & Privacy: Enforce authorization boundaries so riders only see their assigned car, while dispatchers see their operational territory.

Non-Functional Requirements

  • Low Latency: End-to-end update latency from vehicle broadcast to client rendering should be under 500 ms (p95).
  • High Availability & Fault Tolerance: Ingestion must maintain 99.99% availability; temporary vehicle network disconnections must not corrupt vehicle state.
  • Durability: Historical telemetry must be persisted durably without dropping events under peak load.

Scale Assumptions

  • Fleet Size: 50,000 active robotaxis.
  • Ping Frequency: 1 ping per second per vehicle (50,000 incoming updates/sec).
  • Payload Size: ~500 bytes per message (~25 MB/s ingestion bandwidth).
  • Consumers: ~5,000 concurrent fleet operators viewing different regions, and ~100,000 concurrent riders tracking trips.

Key Design Areas to Cover

  1. Data Ingestion & Protocols: Transport layer between vehicles and edge gateways (e.g., MQTT, gRPC, WebSockets) and buffering architecture.
  2. Storage Architecture: Dual-path storage strategy for ephemeral fast state (hot data) versus historical time-series logs (cold data).
  3. Spatial Indexing & Subscription Model: How to partition the world (e.g., H3, S2, Geohashes) to avoid broadcasting all 50,000 updates to every connected dispatcher.
  4. Client Delivery: Protocol and connection management for fan-out to web and mobile clients.

Hints

Hint 1

Differentiate the transport protocols for vehicle-to-cloud ingestion (e.g., lightweight MQTT or persistent gRPC) versus cloud-to-client streaming (e.g., WebSockets or Server-Sent Events).

Hint 2

Use a spatial indexing system like Uber's H3 or Google's S2 to map coordinates into discrete cells, enabling efficient pub/sub routing by geographic interest.

Hint 3

Separate the read path into an in-memory hot cache for latest coordinates and an append-only time-series store for trajectory replay.

Follow-up questions

  • How does your system handle buffered, out-of-order pings sent when a vehicle regains connectivity after exiting an underground parking structure or tunnel?
  • If dispatchers need to draw arbitrary, dynamic polygon geofences rather than standard grid tiles, how does the subscription and filtering mechanism adapt?
  • What dead-lettering, rate-limiting, and backpressure strategies would you introduce if a cellular tower outage causes thousands of vehicles to reconnect and dump backlogs simultaneously?