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.

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.

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.

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