Practice/Google/Design a Proximity Alert System for Apple Tags

Design a Proximity Alert System for Apple Tags

System DesignMust

Problem Statement

Bluetooth-enabled tracking tags like Apple AirTags allow users to attach small devices to personal belongings and track their location through a companion app. A critical feature of these tags is proximity alerting — notifying the owner when a tagged item moves beyond a defined radius, such as when a bag is left behind at a restaurant or a pet wanders out of the yard.

Building this system involves continuous location updates from millions of devices, each reporting noisy Bluetooth Low Energy (BLE) and GPS signals. Raw signals fluctuate significantly due to environmental interference, signal reflections, and varying satellite visibility. A naive implementation that triggers an alert on every out-of-range reading would flood users with false alarms, while being too conservative would miss genuine separation events.

You need to design a backend system that ingests real-time location streams from tags (relayed through nearby smartphones), determines when a tag has genuinely left its owner's proximity, and delivers timely push notifications — all while respecting the severe battery constraints of both the tag hardware and the relay devices.

Key Requirements

Functional

• Proximity Zone Configuration -- Users can define a proximity radius for each tag (e.g., 50 meters) and customize alert preferences such as delay thresholds and quiet hours.
• Real-Time Location Ingestion -- The system continuously receives location updates from tags relayed through nearby devices, normalizing BLE signal strength and GPS coordinates into a unified position estimate.
• Separation Detection -- The system determines when a tag has moved outside the configured proximity zone for a sustained period, distinguishing genuine separations from transient signal noise.
• Alert Delivery -- When a separation event is confirmed, the system sends a push notification to the owner's device with the tag's last known location and a map link.

Non-Functional

• Scalability -- Support hundreds of millions of active tags, each reporting location updates every few seconds to every few minutes depending on movement state.
• Latency -- Deliver separation alerts within 30 seconds of a confirmed separation event.
• Battery Efficiency -- Minimize the frequency and payload size of location reports to extend tag battery life beyond one year.
• Reliability -- Never miss a genuine separation event; tolerate brief communication outages by reconciling state when connectivity resumes.

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Signal Noise and Debouncing

BLE signal strength is notoriously unreliable. Interviewers want to see how you avoid false positives without introducing unacceptable detection delay. Hints to consider:

• Think about a hysteresis-based approach where a tag must be out-of-range for N consecutive readings (or T seconds) before triggering an alert, and must be in-range for a similar threshold before clearing.
• Consider how you fuse BLE RSSI values with GPS coordinates when both are available to produce a more reliable distance estimate.
• Evaluate a sliding-window average or exponential moving average to smooth noisy signal readings before making proximity decisions.
• Think about how environmental factors (walls, crowds, weather) affect BLE range and whether the system should adapt thresholds based on historical signal patterns for a specific tag.

2. Stateful Stream Processing

Each tag maintains an ongoing proximity state that evolves with every location update. Interviewers probe how you manage millions of concurrent state machines. Hints to consider:

• Consider partitioning tag state by tag ID across Kafka consumer groups, so each partition's consumer holds the state for a deterministic subset of tags.
• Think about what state you need to persist (current zone status, timestamp of last zone transition, debounce counter) and whether Redis or an embedded state store (like Kafka Streams' RocksDB) is more appropriate.
• Evaluate what happens when a consumer crashes — how do you recover tag state without missing events or sending duplicate alerts?
• Consider how you handle tags that stop reporting (owner's phone dies, tag goes out of relay range) — do you trigger a "last seen" alert after a timeout?