Airspace Subscriptions

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

Airspace Subscription

Context

Uncrew (and potentially others in the future) require a mechanism for receiving updates to geographic region(s) that could affect planning and/or operations. It is mission-critical for these updates to be as close to real-time as possible. Temporary Flight Restrictions (TFRs) are a good example. The FAA can issue one at any time, effective immediately.

Polling for these changes might result in undue delay, so the intent is to provide a way for clients to subscribe to specific geographic region(s) and then any updates that are applicable to airspace in that region will be pushed to the client.

Decision

We’ve taken a couple starts at solving this, buiding a working POC using both webhooks and websockets. We’ve decided to adopt gRPC to enable streaming of real-time airspace updates. This decision aligns well with our requirement for low-latency communication. The protocol is highly extensible and supports programmatic subscription creation, which is key given our specific airspace subscription needs.

Invalid Image Path

Consequences

Pros

• Streaming: The support for server and client streaming fits well for pushing real-time airspace updates.
• API Evolution: Strong support for API versioning through proto files, making changes formally trackable.
• High Performance: Given the real-time nature of the service, gRPC’s speed and efficiency make it a solid choice.
• Low Latency: Optimized for quick data transmission, aligning with your real-time needs.
• Paved Path: gRPC is already a paved path for use as public API.

Cons

• Long-lived Connections: Like WebSockets, gRPC also requires managing persistent connections. However, it benefits from HTTP/2 multiplexing to handle concurrent streams more efficiently.
• Protocol Buffers Requirement: One more thing to manage.
• Debugging Difficulty: Binary format may make debugging less straightforward.
• Initial Setup Cost: Some ramp-up time required to set up and integrate with existing services.

Alternatives Considered

1. WebSockets

   • Pros

     • Real-time communication: Allows for instantaneous data push from the server, reducing latency.
     • Full-duplex channels: Enables two-way communication simultaneously, which can make interactions more efficient.
     • Protocol flexibility: Can be used in various types of clients, not just web browsers, allowing for a wide range of applications.

   • Cons

     • Not approved for use as a public API
     • Added complexity for scaling: To manage multiple connections across different WebSocket server processes, a shared datastore or message broker is needed. This adds another layer of architecture, making it more complex.
     • Connection Maintenance: Keeping the connection alive might consume resources, especially for numerous clients.
     • Connection overhead: Because connections are persistent, resources on both server and client could be tied up, leading to potential performance issues over time or with high volume.
     • Not Ideal for Sporadic Updates: If updates are infrequent, maintaining a constant connection might be overkill.

2. Webhooks: Simple and straightforward.

   • Pros

     • Standard Protocol: Widely supported, making it easier to integrate with various client technologies.
     • Simplicity: Easy to set up without the need for constant connection management.
     • Loose Coupling: The server and client are less dependent on each other, making the system more resilient.
     • Server-Initiated: Only sends data when there’s something new, reducing unnecessary network chatter.

   • Cons

     • Client-Side HTTP Endpoint Required: Each client must set up and maintain their own authenticated HTTP endpoint to receive updates, adding to the client’s responsibilities.
     • Client-side Authentication Required: Credentials to be used on update requests need to be provided when registering the webhook.
     • Scaling Complexity: Handling multiple active connections requires a data store for coordination.
     • Retry Mechanism Required: If the client fails to acknowledge receipt, a retry mechanism is often needed, adding to the complexity.

3. Google Pub/Sub

   • Pros

     • Scalability: Built to automatically scale, handling a large number of messages without manual intervention.
     • Fully Managed: No need to maintain any servers or message brokers.
     • Durability: Offers message storage until successfully consumed, adding a layer of reliability for mission-critical updates.
     • Event-Driven: Fits well with the real-time, event-based nature of the service.
     • Access Control: Built-in security and access control features could be beneficial.

   • Cons

     • Subscription Granularity: If each geographic region requires its own Pub/Sub subscription and topic, management could become cumbersome.
     • Filtering Complexity: Implementing client-specific filters for message delivery could introduce extra layers of logic and complexity.
     • Limited Real-time Filtering: Pub/Sub might not offer the granular, real-time filtering we require, leading to extra post-processing steps.
     • Not Ideal for Public API: More suited for internal communication, making it complex to expose as a public-facing API.