Bird
Raised Fist0

Design a Real-Time Location Tracking System - GPS, WebSocket, Geo-indexing

HLDhardInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Mobile Client

Sends GPS location update

Client sends current GPS coordinates over WebSocket

Protocol:WebSocket
BeforeClient has new GPS coordinates ready to send
AfterLocation update sent over WebSocket to Ingestion Layer
Ingestion Layer

Receives and forwards location update

Nginx + Envoy receive WebSocket message and produce to Kafka

Protocol:Kafka Produce
BeforeLocation update received on WebSocket connection
AfterLocation update durably stored in Kafka Cluster
Stream Processing

Consumes and processes location update

Apache Flink consumes from Kafka, enriches and splits data streams

Protocol:Kafka Consume/Produce
BeforeLocation update available in Kafka topic
AfterProcessed update produced to Geo-Indexed and Time-Series DB topics
Geo-Indexed DB

Stores spatial data

Cassandra + GeoMesa index location for geo queries

Protocol:Kafka Write
BeforeProcessed location update ready for geo indexing
AfterLocation data indexed and stored for spatial queries in Cassandra
Time-Series DB

Stores temporal data

Cassandra + ScyllaDB store location with timestamp

Protocol:Kafka Write
BeforeProcessed location update ready for time-series storage
AfterLocation data stored for historical time-series queries in Cassandra
Redis Pub/Sub

Publishes update notification

Publishes location update event to subscribed WebSocket servers

Protocol:Redis Pub/Sub
BeforeNew location data stored in DBs, no notification sent
AfterNotification published to WebSocket Streaming Servers
WebSocket Streaming Servers

Pushes update to client

Netty servers receive Redis event and push update via WebSocket

Protocol:WebSocket
BeforeClient subscribed but not yet received latest location update
AfterClient receives real-time location update over WebSocket
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Mobile Client │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────────────┐
│  Ingest Layer (Nginx) │
│  + Envoy              │
└───────┬───────────────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────────────────────┐
│ Stream Proc (Flink + Kafka)   │
└───────┬───────────────┬───────┘
        │ Kafka Produce  │ Kafka Write
        ▼               ▼
┌───────────────┐   ┌───────────────┐
│ Geo-Indexed DB│   │ Time-Series DB│
│ (Cass + GeoMesa)│  │ (Cass + Scylla)│
└───────┬───────┘   └───────┬───────┘
        │ Redis Pub/Sub        │ Redis Pub/Sub
        ▼                     ▼
┌───────────────────────────────┐
│ WebSocket Stream Servers      │
│ (Netty + Redis Pub/Sub)       │
└───────┬───────────────────────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Mobile Client │
└───────────────┘
Design Rationale

This architecture handles real-time GPS location updates by ingesting data via WebSocket through a load balancer (Nginx + Envoy). The updates are durably queued in Kafka, ensuring ordered and fault-tolerant streaming. Stream Processing (Apache Flink + Kafka Streams) enriches and splits the data for storage in two specialized databases: Geo-Indexed DB for spatial queries and Time-Series DB for historical analysis. Redis Pub/Sub acts as a low-latency notification layer to inform WebSocket Streaming Servers of new updates. These servers push the processed location data back to subscribed clients in real time. This design balances durability, scalability, and low latency for location tracking.

Primary Focus

✓

Practice

(1/5)
1. A hotel booking system must prevent double bookings when multiple users try to reserve the same room simultaneously. Which component is best suited to enforce this constraint reliably?
easy
A. Use a distributed lock service like ZooKeeper to coordinate reservation attempts
B. Use a relational database with unique constraints on room and date columns to prevent duplicates
C. Use an eventually consistent NoSQL store with last-write-wins conflict resolution
D. Use client-side validation to check room availability before submitting reservations

Solution

  1. Step 1: Identify the need for strong coordination

    Preventing double booking requires distributed synchronization to ensure only one reservation succeeds for a room at a given time.

  2. Step 2: Evaluate coordination mechanisms

    Relational DB unique constraints (Use a relational database with unique constraints on room and date columns to prevent duplicates) can help but may cause high contention and deadlocks at scale. NoSQL with last-write-wins (Use an eventually consistent NoSQL store with last-write-wins conflict resolution) allows conflicts and can cause double bookings. Client-side validation (Use client-side validation to check room availability before submitting reservations) is unreliable due to race conditions. Distributed lock service (Use a distributed lock service like ZooKeeper to coordinate reservation attempts) provides strong consistency and coordination across distributed components.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Distributed locks coordinate concurrent reservations reliably [check]
Hint: Distributed locks ensure exclusive access to shared resources [check]
Common Mistakes:
2. If the Kafka cluster used for fan-out events crashes and loses the latest messages, what exactly breaks in the newsfeed delivery?
medium
A. The system falls back to synchronous push, increasing write latency
B. Posts published just before the crash are lost; followers never see them
C. Followers receive duplicate posts due to re-delivery attempts
D. Delivery Workers block indefinitely waiting for missing messages

Solution

  1. Step 1: Understand Kafka's role in fan-out

    Kafka buffers fan-out events; Delivery Workers consume from Kafka to deliver posts asynchronously.

  2. Step 2: Trace failure impact

    If Kafka crashes and loses messages, Delivery Workers waiting on those messages block or stall, causing delivery delays.

  3. Step 3: Eliminate other options

    Duplicates (A) occur with retries, not loss. Lost posts (B) happen but are not the immediate failure mode. Fallback to synchronous push (D) is not automatic.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Kafka crash causes Delivery Workers to block waiting for lost messages [check]
Hint: Kafka crash blocks Delivery Workers waiting for messages [check]
Common Mistakes:
3. If the message queue (e.g., Kafka) between the upload service and transcoding pipeline fails, what exactly breaks in the video processing flow?
medium
A. Uploaded videos are accepted but never reach transcoding, so no processed versions are generated
B. Upload service blocks until transcoding completes, causing upload timeouts
C. Videos are transcoded multiple times causing duplicate outputs
D. View counts increment incorrectly due to missing transcoding metadata

Solution

  1. Step 1: Trace failure impact of message queue outage

    The queue decouples upload and transcoding. Without it, upload service cannot enqueue transcoding jobs. Uploads succeed but transcoding workers receive no tasks, so no processed videos are generated. Blocking upload (B) is incorrect because upload is asynchronous. Duplicate transcoding (A) is unrelated. View count errors (D) happen downstream, not due to queue failure.

  2. Step 2: Confirm exact failure mode

    Uploads accepted but stuck before transcoding is the precise failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Queue failure causes transcoding jobs to be lost, no processed videos [check]
Hint: Queue failure means no transcoding jobs dispatched [check]
Common Mistakes:
4. Without the message broker (e.g., Kafka) in a high-throughput chat system, what exactly breaks in the message delivery flow?
medium
A. Messages are sent synchronously causing sender blocking and message loss on receiver failure
B. Alice's send operation blocks until Bob's server responds; if Bob's server crashes, the message is lost with no retry
C. Messages are encrypted incorrectly causing security breaches
D. The system automatically switches to batch mode causing high latency

Solution

  1. Step 1: Role of message broker

    Broker decouples sender and receiver, enabling asynchronous delivery and retries.

  2. Step 2: Consequence of missing broker

    Without it, messages are sent synchronously causing sender blocking; if receiver crashes, messages are lost; encryption (A) unaffected; blocking and loss (C) is exact failure; batch mode (D) not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Broker removal causes blocking sends and message loss on receiver failure [check]
Hint: No broker means synchronous sends block and lose messages [check]
Common Mistakes:
5. At 10x scale, which component in an HTTP/3 deployment is most likely to become the bottleneck first and why?
hard
A. WebSocket servers because HTTP/3 does not support WebSockets natively
B. TLS handshake CPU load on servers due to QUIC's per-connection encryption overhead
C. UDP packet loss rate increases causing retransmissions and latency spikes
D. TCP connection limits because HTTP/3 uses TCP under the hood

Solution

  1. Step 1: Identify HTTP/3 transport and encryption

    HTTP/3 uses QUIC over UDP with built-in TLS encryption per connection, increasing CPU load for handshake and encryption at scale.

  2. Step 2: Eliminate other bottlenecks

    UDP packet loss is network-level, not server bottleneck; WebSockets are not natively supported by HTTP/3 but unrelated to scaling HTTP/3 itself; HTTP/3 does not use TCP.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    QUIC's per-connection TLS handshake CPU load limits HTTP/3 scale [check]
Hint: QUIC TLS handshake CPU load limits HTTP/3 scale first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard