Katkat
Back

Design Radius-Based Notifications from Mobile Locations

Fora TravelSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Tests the ability to design an end-to-end location ingestion and geo-fenced notification system, focusing on spatial indexing, staleness filtering, scalable fan-out, and hotspot mitigation.

Scenario

A modern travel platform connects travelers with local experiences, advisors, and urgent trip alerts. You are tasked with designing a backend service that tracks mobile device locations in real time and delivers push notifications to all users currently located within a defined radius (e.g., 5 km) of a specific geographic coordinate.

Requirements

Functional Requirements

  • Location Ingestion: Accept periodic location updates (latitude, longitude, timestamp, accuracy) from active mobile devices.
  • Radius-Based Trigger: Provide an internal API for administrators or automated services to send a broadcast message to all users within radius R of coordinate (lat, lon).
  • Freshness Filtering: Exclude stale location records (e.g., devices that have not reported a position within the last 15 minutes).
  • Notification Delivery: Durably deliver push notifications (APNs / FCM) to identified users without duplicate sends for the same campaign.

Non-Functional Requirements

  • Scale: 10 million Daily Active Users (DAU), with up to 100,000 location updates per second at peak.
  • Latency: Notifications must begin dispatching within 10 seconds of a campaign trigger.
  • Efficiency: Minimize storage and compute overhead while avoiding broadcast storms in high-density areas (hotspots like airports or major city centers).
  • Privacy: Retain only necessary recent location data and provide mechanisms to prevent exact user position leaks.

What to Cover

  1. API Design & Data Models: Define the ingestion endpoints, campaign trigger APIs, and storage schema for user locations.
  2. Geospatial Indexing: Explain how to store and query spatial data at scale (e.g., Geohash, Google S2, Uber H3, or PostGIS/Redis Geo) and perform exact distance filtering.
  3. Architecture & Pipeline: Detail the pipeline from event trigger to external push gateways, including message brokers, deduplication, and worker pools.
  4. Handling Scale & Hotspots: Address partitioning strategies, sharding for high-density areas, and client battery/staleness trade-offs.

Hints

Hint 1

Separate the high-throughput write path (storing current device coordinates) from the query path by using an in-memory spatial index with a short time-to-live (TTL).

Hint 2

Use a discrete global grid system (like Uber H3 or Google S2) to map the circular search area to a fixed set of cell IDs, converting a complex 2D geometric query into a fast key-value lookup.

Hint 3

For durable fan-out, push candidate user IDs into a distributed message queue with idempotency keys to handle worker failures and prevent duplicate notifications.

Follow-up questions

  • How would you handle a campaign triggered over a major hub like Paris or JFK Airport, where a single query might match hundreds of thousands of users simultaneously?
  • How does the client battery consumption profile influence your server-side design, and how would you handle devices transitioning between background and foreground states?
  • If users require strict location privacy (e.g., GDPR/CCPA), how would you alter the storage and indexing layer to ensure compliance without breaking radius queries?