Keeping Flightwall fast at tens of millions of requests a day
How XORS Studio helps Flightwall serve tens of millions of daily requests while preparing v4 and Flightwall Plus: shared processing, fast local reads, and bounded dependencies.
In this note · 7 sections
Flightwall handles tens of millions of requests a day. For the person looking at a display, all of that traffic comes down to a simple promise: glance up, and the information you need is there.
At XORS Studio, we’ve been working with the Flightwall team on the systems behind that experience. As Flightwall prepares to release v4 alongside Flightwall Plus, the challenge is supporting more capability while keeping the repeated work of serving displays under control.
Plus adds a more personal use case: bringing a crew member’s upcoming flights onto a display at home. That adds account state, schedules, and device links to a product that already needs timely flight information.
At this volume, a small amount of unnecessary work on each request becomes a large amount of unnecessary work over a day. Our approach centers on sharing computation, keeping reads local, and putting limits around slow dependencies.
Do shared work once
When many displays need information about the same aircraft, repeating the expensive processing for every display makes growth unnecessarily costly.
Flightwall separates shared flight processing from the services answering device requests. The processing layer prepares a reusable view of the flight data. The serving layer uses that view to answer each display’s question.
That separates two kinds of growth. Adding displays increases the work of serving responses, without requiring every display to trigger the full processing pipeline.
It also gives us a clear boundary between the product’s internal data processing and the information a display needs to render.
Make nearby flights cheap to find
A display interested in nearby aircraft should not have to search the entire flight dataset on every request.
The serving layer keeps flight data in memory and organizes it into geographic cells. A request can start with the relevant cells, then apply the display’s filters. Separate indexes support direct flight lookups.
Fresh data is built into a new set of indexes before the service replaces the current view. The replacement holds a lock briefly; readers then work against a consistent view.
This keeps the background work of refreshing the dataset from holding up every display reading it.
Design the cache for a bad day
A cache helps most when its behavior under pressure is deliberate.
Suppose many requests arrive for the same uncached configuration. Flightwall combines those requests into one shared load. Each caller has its own wait limit, while the shared load has a separate lifetime. One caller disconnecting cannot cancel work that other displays still need.
Different keys can still create too much work at once, so the cache also limits concurrent loads. When a dependency fails, a temporary backoff prevents every new request from immediately trying it again.
Where the feature permits it, the cache can serve the last good result. Failed reads do not replace that result with an incomplete response.
These controls address different problems: duplicate work, excessive concurrency, repeated failures, and loss of usable cached data. A cache needs more than an expiry time.
Keep a slow feature from slowing the display
Plus introduces additional reads for linked devices and schedules. Those reads need a budget of their own.
Flightwall bounds how long the flight response waits for Plus data. When those reads fail, the core flight response can still complete. Previously loaded Plus data can bridge a short interruption, with an age limit on how long it remains usable.
We also cache schedule inputs separately from the time-sensitive decision about which flight is active. That decision is evaluated against the current time on each request.
The distinction matters. Reusing a schedule should not freeze the display’s idea of which flight is happening now.
Make configuration changes survive concurrent reads
Caching creates a subtle race when a customer changes a setting.
An old read can start before the change, finish after it, and put the previous value back into the cache. Simply deleting the cached value does not prevent that.
Flightwall tracks invalidation against in-flight loads for the affected key. A superseded load cannot repopulate the cache with the old value. New readers can join work associated with the newer state.
The serving system also carries configuration invalidations between regions. That matters when the phone saving a setting and the display reading it reach different servers.
Fast reads only help if the customer’s changes take effect correctly.
Spend bandwidth on changes
Repeated polling does not have to mean repeatedly transferring identical data.
The serving layer uses conditional requests when refreshing its shared flight view. If the view has not changed, the processing service can respond without sending the body again. Changed views use a compressed binary representation.
The API can also suggest a slower polling cadence when no flights are nearby.
Each technique removes a different kind of repetition: transferring unchanged data, sending unnecessarily large updates, or asking as frequently when there is little to show.
Build for the glance
The customer experiences all of this as a display that answers a small question: what’s flying nearby, or which flight is my family member taking?
Our work on Flightwall v4 and Plus has focused on making that answer inexpensive to serve, consistent when settings change, and resilient when a dependency is slow. Tens of millions of daily requests make those decisions part of the product experience.
The patterns reinforce each other. Shared processing reduces repeated computation. Local indexes shorten reads. Bounded loads protect dependencies. Careful invalidation preserves correctness.
That is the engineering we want behind a display people can leave on and trust throughout their day.
