Design a Drone Traffic Control System (UTM)

Problem Statement: Drone Traffic Control (UTM)

Unmanned Traffic Management (UTM) is air traffic control for drones: it decides which drone may fly where and when, and keeps any two from occupying the same piece of sky at the same moment. It is emphatically not a delivery app — a delivery system decides what to carry; UTM decides whether the flight is safe to fly at all and keeps it safe in the air. The output is permission and separation, not packages.

The defining concept is the 4D trajectory: a flight is a path through three spatial dimensions (latitude, longitude, altitude) plus time. Two drones can share the same GPS coordinate safely if they are there at different times or different altitudes; they conflict only when they are too close in all four dimensions at once. So every core operation — planning, approval, conflict detection — reasons over 4D volumes, not 2D points.

UTM runs in two phases. Strategic deconfliction happens before takeoff: an operator submits a planned 4D trajectory, and the system approves it only if it does not conflict with already-approved flights or active no-fly zones. Tactical deconfliction happens in the air: drones stream live telemetry, the system watches for emerging conflicts (a drone drifting off plan, wind pushing two together) and issues resolution commands, up to an emergency ground-all.

The scale that matters is not throughput of requests but safety latency and airspace density. A busy metro might have ~10,000 drones airborne at peak, each streaming position at 1–4 Hz (~20,000–40,000 telemetry messages/second), with ~50,000 flight plans submitted per day. A missed conflict is a midair collision, so — exactly like a robotaxi platform — the design is built around the safety/deconfliction path first and everything else second.