AeroRadar Architecture

Two complementary views of the product: a development workflow built around GitHub Enterprise, and an operational data flow that keeps live flight requests bounded, secure, and provider-aware.

Development and recovery

GitHub Enterprise holds committed source history, pull requests and release references. Work proceeds through review and required checks before merging into main and publishing a reviewed artifact. Source recovery and production-data recovery are separate responsibilities.

Local development, GitHub Enterprise review and main, reviewed artifacts, and controlled Google Play or cloud release — GitHub Enterprise is the source of record. Database and runtime backups are managed separately; OneDrive is not part of this workflow.

Live data and execution

Scheduled AirLabs ingestion publishes a shared flight snapshot to the three-node Valkey cluster. The Cloud Run gateway serves bounded, cached map responses to Android; ordinary map reads do not trigger paid live-provider refreshes. Firebase Auth, Google Play and the Cloud KMS-backed account authority support identity, purchases and account lifecycle operations. Resend delivers transactional account emails, including verification, password reset and security notifications.

Redis live flight history: the history worker appends observed positions from published live generations to Redis/Valkey flight sessions. The gateway reads these retained tracks for flight paths and Sky Replay, separately from the current live snapshot. History has bounded retention and depends on available observations.

Scheduled AirLabs ingestion to Redis and Valkey HA with live flight history, Cloud Run gateway and Android, with Firebase Auth, Google Play, KMS-backed account services, Resend, durable storage and private Operations — Current implementation overview, September 18, 2026. Open the diagram for a full-size view. Schedule/status fallback adapters are separate from the live-map feed; retired PocketWorld and Aviation Edge are not active providers.