How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Uber.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Uber during technical interviews.

Design driver heat map and discuss consensus

Quick 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.

Quick Overview

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.

Design driver heat map and discuss consensus

Quick Overview

Real-Time Driver Heat Map with Top-K Busiest Cells, Plus Paxos vs. Raft

Context

Requirements

Deliverables

Solution

Comments (0)

Design driver heat map and discuss consensus

Quick Overview

Real-Time Driver Heat Map with Top-K Busiest Cells, Plus Paxos vs. Raft

Context

Requirements

Deliverables

Solution

Comments (0)