Design a Real-Time Collision Warning System for Drones in Shared Airspace

Design a system that tracks drones flying in shared airspace and warns the people responsible for them when two drones are on course to come dangerously close. The drones report their own position and motion over a network, and the system has to turn that stream into timely, trustworthy alerts. Only the prompt itself was reported from this interview, so the scope below is a standard reading of it. Treat each point as an assumption to confirm with the interviewer rather than a given. ### Constraints and Clarifications - Assume cooperative drones: each one periodically reports an identifier, a timestamp, a 3D position (latitude, longitude and altitude) and a velocity. - Assume the system must warn before a conflict happens, not just report one, which means predicting positions over a short look-ahead horizon. - Assume alerts go to human operators and to the drones' ground-control software; whether the system may also command an avoidance maneuver is an open question. - This is a safety system: a missed alert is far worse than a false one, but too many false alerts teach operators to ignore them. ### Clarifying Questions - How many drones are airborne at once, over how large an area, and how often does each one report? - What separation counts as a conflict, horizontally and vertically, and how far ahead should the system look? - Should the system also track objects that do not report themselves, such as crewed aircraft seen through external feeds? - Who receives an alert, how quickly must it arrive, and must it be acknowledged? - Is the system advisory only, or may it issue avoidance instructions? - How accurate and how fresh is a reported position, and what should happen when a drone stops reporting? ### Part 1 — Ingesting telemetry and tracking state Describe how position reports get from the drones into the system and how you keep an up-to-date view of every drone. Cover the ingestion path, ordering and duplicate reports, timestamps and clock differences, and how you represent a drone whose data has gone stale. ```hint Last known is not current A position that is a few seconds old describes a region, not a point; decide how the age of a report should change what the system believes. ``` #### What This Part Should Cover - A durable, partitioned ingestion path that absorbs bursts and duplicates - Per-drone state keyed by identifier and ordered by the drone's own timestamps - Explicit handling of stale or missing reports and of position uncertainty - Authentication of the telemetry channel, since spoofed positions defeat the system ### Part 2 — Detecting conflicts Explain how you find pairs of drones that will violate separation within the look-ahead horizon without comparing every drone with every other drone. Describe the conflict test for a single pair and how the work is split across machines. ```hint Only neighbors can collide soon Over a short horizon a drone can only travel a bounded distance; use that bound to limit which pairs are worth testing. ``` #### What This Part Should Cover - A spatial partitioning scheme sized from separation, speed and horizon - A pairwise test based on predicted relative motion, not only current distance - Sharding by region, including drones near shard boundaries - Recomputation cadence and its effect on detection latency ### Part 3 — Alerting and reliability Describe how a detected conflict becomes an alert that reaches the right people quickly and stays meaningful: severity levels, de-duplication, updates and resolution, acknowledgment and escalation. Then explain how the system behaves when parts of it fail. ```hint An alert has a lifecycle A conflict between the same two drones persists across many computation cycles; think about what should happen on the first cycle, on the ones that follow, and on the last. ``` #### What This Part Should Cover - Severity tiers tied to the time remaining until closest approach - Per-pair de-duplication, hysteresis against flapping, and an explicit resolved state - Delivery with acknowledgment, escalation and an end-to-end latency budget - Failure handling that fails safe, plus monitoring of the pipeline itself ### What a Strong Answer Covers - Requirements and scale stated up front, with assumptions confirmed rather than invented - Sound geometry: prediction, uncertainty and separation in three dimensions - A design that avoids all-pairs comparison and scales by region - An explicit position on the false-alarm versus missed-alarm trade-off - Low, measured end-to-end latency from report to alert - Safety-minded failure behavior and a testing strategy such as replaying recorded or simulated traffic ### Follow-up Questions - How would the design change if the system had to send avoidance instructions directly to the drones? - How would you incorporate aircraft that do not report themselves and are seen only by radar with noisy positions? - One region suddenly carries ten times its usual traffic. Which component saturates first, and what do you do? - How would you demonstrate to an aviation regulator that the system does not miss conflicts?