Design a Device Tracking Network

Clarified device reporting model (direct GPS/cellular vs crowdsourced BLE relay) before diving into design
Established scale assumptions (device count, ping frequency) and derived approximate write throughput
Distinguished functional requirements: current location, history/playback, geofencing, sharing/ACL
Defined non-functional targets: latency for current-location reads, end-to-end freshness, retention window

Proposed a durable ingestion buffer (queue/Kafka) decoupling ingestion from storage writes
Used a dual-storage strategy: fast key-value/cache for last-known-location + time-series/wide-column store for history
Included a stream/real-time processing layer for dedup, enrichment, and geofence evaluation
Designed a push mechanism (WebSocket/MQTT) for near-real-time client updates, not just polling
Provided clear API surface covering ingestion, current-location read, history read, and geofence management

Addressed write-path scaling explicitly (partitioning by device_id, throughput numbers, LSM-based store choice)
Discussed staleness/offline detection approach and its trade-offs vs a dedicated heartbeat service
Covered data volume/retention management via downsampling or tiered storage for history
Discussed at least one battery/bandwidth or crowdsourced-consensus tradeoff relevant to device constraints
Articulated partition hot-key or skew risk (e.g., high-frequency device) and mitigation

Structured the session with reasonable time allocation across requirements/design/deep dive/wrap-up
Justified each major storage/technology choice with an explicit trade-off rather than asserting it
Summarized design concisely at the end with a clear recap of key decisions

Problem