Production win
Satellite-Optimized Live Tracking
Near real-time delivery with 15% Lambda cost savings
Architecture diagram
Satellite live tracking sync path
A bandwidth-aware sync contract that sends compact deltas over Iridium, then recovers drift with bounded full-field refreshes.
Race trackers
Field position and status changes
Position deltas
Iridium link
340-byte message constraint
Tiny messages
Python sync protocol
Delta encoding, chunking, sequencing
Sequence state
Redis sync state
Short-lived sequence and recovery state
Rebuild context
Reassembly + refresh
Late chunks handled; full field refresh <= 5 min
Trusted live state
Live tracking UI
Operators see a coherent field picture
- Custom protocol kept payloads small enough for satellite transport.
- Refresh path protected the UI from long-running sync drift.
- Redis carried transient ordering and recovery state, not durable business truth.
This one came from a race-tracking setup where the usual assumptions behind real-time software were useless. The product still needed to show a meaningful live picture of the field, but the network path was satellite, Iridium, which meant low bandwidth, small message sizes, irregular delivery, and enough latency that a normal "keep sending state" approach would fall apart fast. The problem was not "how do we make live tracking fast?" It was "how do we make it usable when the transport is hostile to the way most web systems expect to behave?"
Two things broke, and the whole design is shaped by them. The first was bandwidth. Under Iridium the 340-byte message limit is not a side note, it shapes everything. A normal payload simply does not fit through the link at an acceptable cost or latency, so I compressed everything down to a minimal binary protocol and a differential sync that sends only what changed, not the full state every time. I kept a compact model of the race field and pushed deltas that could be applied safely on the other side. On this link, bytes are the budget, and the verbose, convenient format had to go.
The second was packet loss, which over satellite is the normal case, not an edge case. So delivery is strictly sequenced and the receiver tracks what it has actually seen. When a fragment goes missing, the system does not silently skip ahead, it resumes from the last-seen point and pulls the missing piece back, and there is a bounded recovery path with a full-field refresh that stays within roughly five minutes, so the client view can never drift permanently. A missing fragment cannot be allowed to poison the picture. Redis handled short-lived sync state and sequencing; Python handled the protocol and transformation.
What I got was a live system that stayed useful in conditions where it could easily have degraded into a delayed reporting tool, operators still had something they could act on. What I gave up was simplicity: a basic HTTP or JSON feed would have been easier to maintain and hand off, and the custom protocol is more specialized and less forgiving. I also accepted that perfect real-time parity was not the goal, a bounded path back to trustworthy state mattered more than pretending I could offer always-current, fully consistent updates.
I like this project because it forced a very honest kind of engineering. No abstraction could save me from the transport constraint. I had to design for how the medium fails first, compact framing and resume-from-last-seen built into the protocol, and respect the network I actually had, not the one I wished I had.