Blue Origin

Background

I worked on the ground side of satellite telemetry: the software that takes what a spacecraft says about itself and turns it into something an engineer can actually watch. Blue Origin builds spacecraft as well as rockets, and anything in orbit reports back continuously on signal strength, orbital position, and attitude. The value of that data decays quickly. A plot that is five minutes stale tells you where you used to be.

Ingesting the stream

I built Python ingestion services to parse and process high-frequency telemetry streams, which got readings available to downstream consumers in under a second. Telemetry is a firehose of small, strictly formatted records rather than a few large ones, and frames arrive out of order, drop, and repeat. Parsing them is the easy half. The harder half is staying ahead of the stream at peak rate without losing the ordering that everything downstream assumes.

Making it queryable under load

The data lands in TimescaleDB, where ingestion and querying compete for the same machine: engineers filter by spacecraft, channel, and time window at exactly the moment new data is arriving fastest. I tuned hypertable chunk intervals and built indexes for multi-dimensional filtering, which brought query latency down under peak ingestion load. Chunk sizing is most of that problem. Too large and every query scans data it doesn't need, too small and the planner drowns in chunks.

The dashboards

On top of that I engineered React/TypeScript monitoring dashboards backed by FastAPI and SQL endpoints, visualizing signal strength, orbital position, and attitude data. Nobody watches a dashboard idly. They open it because something already looks wrong, so the default view has to answer whether this is normal before anyone touches a filter, and it has to keep answering that while the underlying table is being written to.