Design a Location‑Sharing Service: System Design Interview Walkthrough 2026

When an interview asks you to design a location‑sharing service, the conversation often starts with a vague "Tell me how you'd build it". The key is to turn that open‑ended prompt into a structured discussion. You do this by iterating through requirements, sketching a high‑level architecture, diving into the tricky parts, and finally handling the typical follow‑up questions. Below is a practical walkthrough you can use in any interview.

1. Clarify Requirements

Functional

• Share real‑time location: Users can broadcast their GPS coordinates to a set of trusted contacts.
• Privacy controls: Users choose who sees their location and for how long.
• History view: Optionally retrieve recent location points (e.g., last 24 hours).
• Notifications: Alert a contact when a user enters or leaves a predefined geofence.

Non‑functional

Ask the interviewer which of these are in scope. If they say “focus on real‑time sharing only,” you can deprioritize history and notifications.

2. Identify Core Entities

• User – unique ID, profile, list of contacts, privacy preferences.
• Device – ties a User to a physical phone; holds a push token.
• LocationUpdate – timestamp, latitude, longitude, accuracy, source device.
• ShareSession – defines who can see a location stream, start/end time, optional geofence rules.
• Notification – generated when a geofence condition is met.

These entities map naturally to tables or collections in your data layer.

3. Sketch the API

POST /share/start
  { "targetIds": ["userA","userB"], "expiresIn": 3600 }

GET /share/{sessionId}/stream
  // Server‑Sent Events or WebSocket

POST /location
  { "lat": 37.7749, "lon": -122.4194, "accuracy": 5 }

GET /history/{userId}?since=2026-09-01T00:00:00Z

Explain that the /share/start call creates a ShareSession, returning a session token the client uses for the streaming endpoint. The streaming endpoint can be a WebSocket for low latency or Server‑Sent Events for simplicity.

4. High‑Level Architecture

+----------------+      +----------------+      +-------------------+
| Mobile Client  | ---> | API Gateway    | ---> | Auth Service       |
+----------------+      +----------------+      +-------------------+
                               |                     |
                               v                     v
                     +----------------+   +-------------------+
                     | Location Ingest|   | Session Manager   |
                     +----------------+   +-------------------+
                               |                     |
                               v                     v
                     +----------------+   +-------------------+
                     | Stream Service |   | Notification Svc |
                     +----------------+   +-------------------+
                               |                     |
                               v                     v
                     +---------------------------------------+
                     | Data Store (Geo‑partitioned)          |
                     +---------------------------------------+

• API Gateway handles routing, rate‑limiting, and TLS termination.
• Auth Service validates tokens (OAuth2/OpenID Connect) and injects user context.
• Location Ingest receives high‑frequency GPS points, validates accuracy, and writes to a time‑series store.
• Stream Service pulls the latest point for each active session and pushes it to subscribed clients via WebSocket.
• Notification Service watches geofence rules (often in a rule engine like Redis Streams) and fires push notifications.
• Data Store uses a geo‑partitioned key‑value store (e.g., DynamoDB with geohash) for fast range queries and a time‑series DB for history.

5. Deep Dive: Real‑Time Ingestion & Delivery

5.1 Handling High‑Frequency Updates

Mobile devices can emit a location every few seconds. To avoid overwhelming the system:

• Client‑side throttling: Send only when movement > X meters or time interval > Y seconds.
• Batch writes: Aggregate updates in the client SDK and send a small batch (e.g., 5 points) per request.
• Back‑pressure: If the ingest service detects overload, it returns a 429 and the client backs off.

5.2 Low‑Latency Streaming

WebSocket is the usual choice because it keeps a persistent TCP connection, allowing the server to push updates instantly. Alternatives:

• Server‑Sent Events: Simpler, works over HTTP/1.1, but less flexible for bidirectional control.
• gRPC streaming: Good if the stack already uses protobuf, but requires native client libraries.

5.3 Ordering & Consistency

GPS data can arrive out of order due to network jitter. Include a timestamp with each point and let the stream service reorder before broadcasting. For most use‑cases, eventual consistency is acceptable; you don't need strict linearizability.

6. Hard Parts & Trade‑offs

Discuss whichever dimension the interviewer seems most interested in. For example, if they ask about “how you’d protect user privacy,” walk through per‑session encryption keys and how the server never sees plaintext coordinates.

7. Follow‑Up Questions Interviewers Often Ask

1. How would you handle offline users?
   • Buffer updates in the client and sync when connectivity returns. Server can store a short backlog (e.g., last minute) for late joiners.
2. What if a user wants to share location with 10 k contacts?
   • Use a fan‑out service: write the update once, then push to a fan‑out queue that delivers to each subscriber asynchronously.
3. How do you enforce rate limits per device?
   • Token bucket algorithm at the API gateway, keyed by device ID.
4. Can you support “location history export” as a CSV?
   • Query the time‑series store for the requested window, format rows on the fly, and stream the file back to the client.
5. What if the service needs to run in multiple regions?
   • Deploy the ingest and stream services in each region, replicate the geo‑partitioned store via eventual‑consistency replication, and route users to the nearest region via DNS.

8. How to Practice This

1. Mock the interview – Use a timer, write the requirements on a whiteboard, and walk through each section out loud.
2. Record yourself – Let Call Assistant listen and draft a concise answer; then compare the draft to your spoken version and refine.
3. Focus on trade‑offs – Pick one hard part (e.g., privacy) and rehearse explaining at least two alternative designs and why you’d choose one.

---

FAQ

• What is the most important non‑functional requirement for a location‑sharing service? Low latency is usually critical because users expect near‑real‑time maps; however, privacy is equally important and often drives architectural choices.
• Do I need a separate service for geofence alerts? It’s common to separate geofence evaluation from the main streaming pipeline to keep the real‑time path lightweight.
• How much data does a single location update consume? A GPS point (latitude, longitude, timestamp, accuracy) is typically under 100 bytes; batching reduces overhead further.
• Can I use a relational database for storing locations? You can, but time‑series or key‑value stores with geo‑partitioning usually offer better write throughput and query performance for this use case.