Live Location Sharing App

0Problem RestatementProblem

Design a real-time location sharing system similar to WhatsApp Live Location. Users should be able to share their live coordinates with individuals or groups for a fixed duration. Key challenges include maintaining low-latency updates (< 2s) for millions of concurrent users while optimizing for mobile battery consumption and gps accuracy.

1RequirementsRequirements

1.1 Functional

• Share Live Location: Real-time sharing with 1:1 contacts or groups.
• Stop Sharing: Manual override to stop sharing at any time.
• Auto-Expiry: Sharing automatically ends after a chosen duration (15m, 1h, 8h).
• Real-time Map: View others' moving locations on a map interface.

1.2 Non-Functional

• Low Latency: Updates must reach friends in near real-time (< 2–3s delay).
• High Scalability: Support millions of concurrent sharers and viewers.
• Reliability: System should be fault-tolerant; server restarts shouldn't drop active sessions.
• Battery Efficiency: Minimize mobile resource usage (GPS/Network).

1.3 Scale Estimates

• Storage: Temporary in-memory storage for active sessions; no long-term archival needed for core functionality.

1.4 API Design

The core APIs required for the service:

2High-Level ArchitectureArchitecture

2.1 Overview

• Location Service (Write Path): Receives and validates incoming updates, persisting them to a fast in-memory store.
• Pub/Sub Layer: Fan-out service using Redis/Kafka to push updates to all authorized subscribers.
• WebSocket Service: Maintains persistent connections with viewing clients for low-latency delivery.

2.2 Architecture Diagram

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart TB
    U1["Sharer (Mobile App)"] -->|"1. Start/Update"| AG["API Gateway"]
    AG -->|"2. Validate"| LS["Location Service"]
    LS -->|"3. Write with TTL"| Redis[(Redis / In-Memory Store)]
    LS -->|"4. Notify Hub"| PS["Pub/Sub (Kafka/Redis)"]
    PS -->|"5. Fan-out"| WS["WebSocket Service"]
    WS -->|"6. Push Update"| U2["Friend (Mobile App)"]
    
    classDef sharer fill:#f0faff,stroke:#0077be,stroke-width:1px;
    classDef viewer fill:#f0fff4,stroke:#228b22,stroke-width:1px;
    classDef core fill:#fff5f5,stroke:#dc3545,stroke-width:1px;
    class U1 sharer;
    class U2 viewer;
    class LS,WS,Redis,PS,AG core;

3Components Breakdown

3.1 Client (Mobile App)

• Adaptive GPS polling based on user activity.
• Efficient batching of location data where possible.
• Persistent WebSocket connection for background updates.

3.2 Fan-out: Who Is Watching Whom

• Session record: share:{session_id} → sharer, allowed viewers, expires_at. Written on start; its TTL is the share duration.
• Latest location: loc:{session_id} → lat, lon, accuracy, timestamp (overwritten on every update, same TTL).
• Connection registry: conn:{user_id} → which WebSocket server holds that user's connection (set on connect, cleared on disconnect, short TTL refreshed by heartbeats).
• Delivery: On each update, the Location Service publishes to channel session:{session_id}. WebSocket servers subscribe to the channels of sessions their connected viewers are watching (subscribe when a viewer opens the chat/map, unsubscribe when they leave), and push to those sockets.
• Viewer opens the map late: read loc:{session_id} once for the current position, then receive live updates.

3.3 Storage Strategy

• Redis TTL: Use session expiry as the TTL (Time-To-Live) for location keys.
• In-Memory Speed: Essential for the 400k+ writes/sec requirement.
• Automatic Cleanup: Redis automatically removes expired session data.

4Scale ConsiderationsScale

• Sharding: Partition Redis by session_id to distribute load.
• Fan-out Handling: Fan-out is small by nature — a share goes to one contact or one group (at most a few hundred members), so Redis Pub/Sub per session is enough. There is no "celebrity" case to design for.
• Connection Routing: A WebSocket stays on one server for its lifetime; what matters is the connection registry (which server holds which user) so updates reach the right server, and reconnecting clients resubscribe wherever they land.
• Geo-Filtering: Only push updates to friends who are actually looking at the map for the specific user.

5Deep Dive Candidate TopicsDeep dive

• Adaptive Precision: Reducing GPS frequency when a user is stationary to save battery.
• Message Delivery Guarantees: Tradeoffs between at-most-once (fast) vs at-least-once (reliable) delivery for live positions.
• Handling Sudden Disconnects: Implementing graceful handovers for mobile network switching.

6Tradeoffs & ExtensionsTrade-offs

• Why Redis TTL vs SQL cleanup jobs? → simplicity, auto-expiry.
• Why WebSocket vs Push Notifications? → low latency vs intermittent.
• Extensions: could add geo-fencing (notify when friend enters area).