Normalize unlike sources
Live positions, historical tracks, route records, airport reference data, and schedule fallbacks arrive in different shapes and serve different purposes.
Personal engineering case study · Aviation data
Building a Real-Time System From Six Data Sources
FlightDetector is a flight-tracking platform and API built by Jiss Tech. It combines six aviation and reference sources according to their actual roles, checks route claims against observed flight evidence, and reuses archived historical data before making another provider request.
6 verified data sourcesArchive-first historyBudget-aware fallbacks
Business / product problem
Aviation sources answer different questions — and can still disagree.
Aviation data can look authoritative until it is compared. Airlines reuse flight numbers across multiple legs a day. Databases store different snapshots of the same flight. Feeds go down without warning, throttle without mercy, and bill per request. No one provider answers every live, historical, route, airport, and airframe question the system needs.
Making six of them behave as one reliable platform forced us to solve, in miniature, every problem that plagues business integrations: data that disagrees, providers that fail, and costs that spiral when nobody is watching.
Product overview
Five decisions behind the source-aware pipeline.
Verification against measured reality
Candidate routes are checked against observed departure and direction evidence. A familiar flight number does not override what the tracked aircraft actually did, and contradictory candidates are rejected.
Archive first, call the API second
Historical answers are stored in SQLite, and a coverage index records which time windows are already archived. Repeat questions reuse local data instead of making avoidable provider calls.
Budgets enforced in the database
Usage counters keyed by calendar month are checked before budgeted fallback calls. Hard caps and per-callsign retry guards keep provider escalation deliberate and observable.
Failing toward honesty
When every source disagrees with the measured evidence, FlightDetector shows "destination unknown" instead of a confident wrong answer. That choice was vindicated the first time a stored route pointed east while the aircraft flew west.
Fallbacks rehearsed before the outage
Primary live-position failures can fall back to OpenSky, while historical and route-resolution paths have their own ordered fallbacks. Each source has a defined job instead of pretending every provider is interchangeable.
Product interface
Live airspace, decoded in real time.
Verified architecture
A source-aware pipeline instead of one supposedly authoritative feed.
FlightDetector is a personal engineering case study. A Fastify API serves a vanilla JavaScript Mapbox interface, normalizes six aviation/reference sources according to their actual roles, checks route claims against observed flight evidence, archives paid historical answers in SQLite, and escalates only when cheaper evidence cannot resolve the route.
Technology
The stack, without the résumé padding.
Every technology below is tied to the audited project source—not to a company-wide capability list.
Frontend
HTMLCSSVanilla JavaScriptMapbox GL JS
Backend
Node.jsJavaScript ES modulesFastify 5Fastify CORS
Data & cache
node:sqliteSQLiteIn-memory TTL cacheCoverage index
Live & historical
adsb.lolOpenSky NetworkFlight tracksArchived windows
Enrichment & reference
adsbdbOurAirportsRoute normalizationAirframe data
Budgeted fallback
AirLabsAviationStackMonthly countersRetry guards
Constraints
What the system had to respect
- Flight numbers are reused across legs, providers disagree, and route metadata can contradict the aircraft's observed movement.
- Some providers are free, some are quota-limited, and historical requests should not be repurchased when the answer is already known.
- The system must remain honest when no source can establish a destination instead of inventing certainty.
Solution
Engineering decisions that answer those constraints
- Use adsb.lol for primary live positions and OpenSky as a live fallback and historical source.
- Build route candidates from adsbdb, adsb.lol route chains, branded/operator variants, learned routes, and archived observations.
- Check SQLite coverage before historical calls and persist fetched flights and covered windows for repeat use.
- Escalate to AirLabs and AviationStack only behind database-backed budgets, then return an explicit unknown state when evidence remains insufficient.
Engineering challenges
Verify the route, not the brand
Candidate legs are compared with measured departure and direction evidence so a familiar flight number cannot override what the aircraft actually did.
Spend requests deliberately
Archive coverage, learned routes, monthly usage counters, hard caps, cache TTLs, and per-callsign guards prevent avoidable provider calls.
Integrations
External systems with defined jobs
- adsb.lol for primary live aircraft positions and route-chain data.
- OpenSky Network for fallback positions, flight tracks, and historical flights.
- adsbdb for route, airline, airport, and airframe enrichment.
- OurAirports for airport codes, names, municipalities, and coordinates.
- AirLabs and AviationStack as budget-controlled destination fallbacks.
- Mapbox GL JS for map rendering and route visualization; it is not counted as an aviation data source.
Reliability & security
Controls visible in the source
- Fastify applies per-IP rate limiting and exposes health information for provider and archive state.
- Upstream requests have bounded timeouts, and primary live failures can fall back to OpenSky.
- Archive writes are idempotent, fetched-window coverage avoids duplicate history calls, and paid fallbacks are protected by monthly counters and retry guards.
- Contradictory or missing route evidence produces an explicit destination-unknown state.
Outcome
What the verified implementation demonstrates
The result is a working personal engineering case study that demonstrates source-aware API integration, route verification, archive-first data access, explicit fallback ordering, and cost controls. It is not presented as a client engagement, a benchmarked performance result, or a quantified savings claim.
Lessons learned
- More providers do not create trust by themselves; provenance and verification rules do.
- A permanent archive turns previous API spend into reusable infrastructure.
- Returning unknown is a reliability feature when every available answer conflicts with observed evidence.
Why this matters for your business
The same patterns make business integrations boring — in the best way.
Cross-source verification, archive-first data, database-enforced budgets, honest failure states, and rehearsed fallbacks are exactly what make CRM syncs reconcile instead of duplicate, webhook pipelines survive vendor outages, and reports stay trustworthy. This is the discipline behind our API integration and development practice.
We've written up the engineering in detail: what building a flight tracker taught us about third-party APIs and how to cut API costs: six strategies that compound.
Have data sources that don't agree?
CRM, billing, vendor feeds — if your systems hold different versions of the truth, we've solved this problem at altitude.