DATA Ingress DAA Telemetry

Andi Lamprecht ·2026-05-11· 4 min read· Accepted

UTM Data Ingress Pattern (DAA & Telemetry)

UTM-1536

Context

Invalid Image Path

UTM is a multi-service system. When data enters the system, other services need to know that arrived and what the
data is.

Examples

DAA Plots

uAvionix shares plots over UDP. For reasons describe below, DAA is a separate service. Subscribers of
plot data subscribe through the API or gRPC service. The plot data needs to make it’s way from DAA
to API and gRPC as quickly as possible.

Telemetry

Telemetry data will enter the system via gRPC and make it’s way to API as quickly as possible.

Decisions

Data Ingress Pattern

1. Persist the Data : Save it in the database.
2. Notify : Post the ids of the saved data to Redis

DAA runs as a separate service.

Decision Drivers

Data Ingress Pattern

In the case of plots and telemetry, the information is ephemeral. That fact might lead one to put the data in a Redis
Stream where the data expires after a certain time. However, storing the data in Postgres offer the following benefits:

• Faster query options
• Less processing while reading data
• Data is more permanent and available for later research
• Easily transferable to archive
• Easily purged

Redis still plays a part. It is the nervous system of UTM. A service the receives data may notify the rest of the
system by posting the id of the newly saved record to a Redis stream. Services interested in the data can subscribe
to the stream and use the id to load the data from Postgres.

DAA as a Separate Service

The DAA service will listen on a UDP port for plot data. The networking concerns alone are reason enough to warrant
separating it. We don’t want to complicate existing services with the extra ingress and firewall restrictions. The
DAA service also has different scaling needs.

Use Case / Logic Flow

1. A residential birthday party near Dallas Love Field Airport needs Pizza now. They place an order with their local pizzeria and request DroneUp delivery.
2. Uncrew submits a flight intent, Mission-Pizza-Now, to UTM.
3. Danny the DroneUp drone pilot is elected to fly Mission-Pizza-Now.
4. Danny opens the UTM Spaces app and begins tracking Mission-Pizza-Now before taking off.
5. Uncrew begins sending drone telemetry to UTM. Danny can see his drone moving on the Spaces map.
6. Meanwhile, George, the GA pilot, is returning home from business trip to his base airport, Dallas Love Field.
7. uAvionix sees George and sends plot data to UTM. We dive into this process below.
8. Danny can see George’s aircraft in the vicinity of his Drone.
9. The Drone is nearing its destination on the approach end of Dallas Love Field.
10. George is on final approach and flying lower and he should be.
11. UTM receives a plot in the DAA service. The plot is saved to Postgres and the ID is streamed through Redis.
12. The API service receives the ID of the plot and loads the data from Postgres.
13. API queries Postgres for active drone flights (telemetry) that are within a 2-mile radius of George in the past 60 seconds.
14. API observes that Mission-Pizza-Now is on a collision trajectory with George.
15. ALERT! API sends a message (websocket) to Danny’s Spaces session.
16. Spaces draws a red circle (OCAV - Own-ship Collision Alerting Volume) around the drone and plays an audible alarm sound.
17. Danny observes the alert and presses the “Defensive Crouch” button on his pilot app.
18. The drone ducks out of the way.
19. George flies safely above the drone and lands. Home at last.
20. Mission-Pizza-Now completes its pizza delivery to a dozen hungry and happy children.

Consequences

• Performance: Sharing data over Redis is faster that saving it in Postgres and then loading it from Postgres.
• Postgres Load: Postgres may need extra maintenance to handle the higher number of write-connections and data churn.

Cited by queries

• Multi-authority approval, telemetry sharing, and authority/org IAM coverage — 2026-04-28