Real-time Flight Updates

A flight is delayed, a departure time changes, or passengers are moved to another gate. Operations teams and partner apps need the same current information so they can respond. When updates arrive late or different systems show different details, teams spend time checking which version to trust. A reliable flight feed helps everyone work from a clearer picture.

How Harper delivers real-time flight updates

Harper brings live messaging, flight records, and application logic together. Your existing flight systems send updates to Harper, which makes them available to the dashboards and partner apps allowed to receive them. Connected applications receive changes as they happen instead of repeatedly asking whether a flight has changed.

The same Harper application also serves flight details and update history over HTTP, the standard connection used by web APIs. A dashboard can open with the latest flight information, receive live changes, and request anything it missed after a lost connection. Messaging and stored records work together in one runtime, giving the team fewer services to connect and maintain.

Some updates also come with larger files, such as a detailed operational report or a batch of flight data. Harper can send a short notification that the file is ready, then deliver it over HTTP when an application requests it. The file stays in object storage and is streamed through Harper, keeping bulky transfers out of the live messaging connection.

Alternatively, a typical build would use separate services

A conventional setup uses a message broker to send live updates, application servers to apply business rules, and a database to hold flight records. An HTTP service provides details and history to applications. These familiar services can work well, but the team must connect their access rules, data updates, and recovery behavior. Expanding into more regions adds more copies of that system to coordinate.

‍

Where coordination adds up across services

An app can reconnect successfully and still show an old departure time. The live feed and stored flight records need to work together to restore what changed while it was offline. With separate services, that recovery crosses several systems. Harper brings messaging, records, and the recovery logic into the same application, making that path easier to build and operate.

Why Harper matters

• A shared view of the flight. Bring live updates and stored records together so teams and partner apps can work from current information.
• Timely updates. Send changes to connected applications as they happen, reducing the need to repeatedly check for new information.
• Simpler recovery. Let reconnecting applications retrieve the latest flight details and missed updates from the same service that delivers the live feed.
• Less infrastructure to manage. Run messaging, flight records, and application APIs together so engineers can spend more time improving the service.
• Easier regional growth. Add regions through Harper Fabric to bring the service closer to more users, with deployment, replication, routing, and failover managed together.

Plan for a reliable flight feed

Start with clear rules for who can publish each flight feed and who can receive it. Decide how long to retain updates and how an app should catch up after losing its connection. The application must recognize repeated or late updates so an older message does not replace a newer departure time. These are part of the flight integration built on Harper.

Keep the original flight systems as the source of truth, and show when information was last updated. If a source stops sending data, Harper can serve the records it already has, but it cannot create new flight information. Test reconnection and catch-up when a Harper region becomes unavailable, as well as when a client loses connectivity.

Related resources

• Getting-Started-PubSub: a public starting point for MQTT and WebSocket messaging in a Harper application. It is not a flight or file-streaming solution.
• acl-connect: a public starting point for access control on connected clients. Use it to explore permissions, not as a complete design for this architecture.

Start with one flight feed

Pilot one flight feed with an operations dashboard and a partner application. Measure how quickly a source change appears in each view, whether they agree on the latest flight details, and how well they recover after a lost connection. Test busy periods and regional outages before expanding. Bring your flight sources, target audiences, and update requirements to a Harper architecture workshop.

‍