Design driver heat map and discuss consensus
Overview
This question evaluates expertise in designing scalable, low-latency real-time systems—covering streaming ingestion via WebSocket, geospatial partitioning into deterministic cells, time-windowed density aggregation and top‑K querying—alongside conceptual knowledge of distributed consensus algorithms (Paxos vs Raft) within the System Design / Distributed Systems domain. It is commonly asked because it probes architectural trade-offs for high-throughput, low-latency geospatial streaming and fault-tolerant replication, combining practical application (component design, data partitioning, real-time aggregation and query serving) with conceptual understanding of consensus protocol differences.
Real-Time Driver Heat Map with Top-K Busiest Cells, Plus Paxos vs. Raft
Context
You are designing a real-time heat map for a ride-hailing platform. Driver apps continuously send location updates. Rider apps (and internal tools) need to visualize where drivers cluster and fetch the top-K busiest cells within a map region/zoom, with low latency.
Requirements
- Real-time ingestion and streaming via WebSocket.
- Partition the map into deterministic cell IDs (e.g., S2/Geohash) that align with map zoom levels.
- Track driver density per cell over a recent time window (e.g., last 1–5 minutes) and serve the top-K busiest cells for a requested viewport.
-
Reasonable scale assumptions (tune as needed):
- 1–5 million active drivers globally.
- Each driver sends a location every 2–5 seconds.
- End-to-end latency: P95 <= 1–2 seconds from driver update to client-visible heat change.
- High availability across regions; horizontal scalability.
Deliverables
- Design the system: ingestion, partitioning, storage, algorithms to maintain and query top-K per region/viewport, and how WebSocket streaming is used.
- Explain Paxos and Raft consensus algorithms and highlight key differences.
Solution
Login required