Airspace Charger Service

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

UTM Airspace Charger Service

Context

Invalid Image Path

UTM receives its airspace data from Atlas’ pub/sub, pushed via HTTP posts to the API service. These request come in
batches, sometimes very large batches, on a daily basis. In the event of a flush, whereby we refresh ALL the
airspace data, tens-of-thousands of requests hit UTM’s endpoint in a matter of minutes. It is an intensive load
that slows response time for all API clients, despite our horizontal scaling.

Decision

Pull the Airspace Charger endpoint out of API and into its own service.

Decision Drivers

The scaling needs of the Airspace Charger are unique and disrupt the API service. With Airspace Charger running
as a stand-alone service, API will no longer suffer from the daily influx of airspace data.

Switch to Pull Consideration

A subscription to Pub/Sub can be “pull” or “push”. What if we switch to “pull”? This may be good idea. However,
it does not remove the motivation for a separate service. Why? API is a service with multiple pod. Which pod
should handle pulling from the Pub/Sub? A separate service avoids this complication.

Consequences

• More Complexity : another service to maintain
• Postgres Load : consumes more of our limited connections to postgresql