To a customer, live tracking is a moving dot on a map and an honest ETA. Underneath, it's a firehose of GPS pings, scan events, and edge cases that all have to reconcile into one trustworthy timeline. Getting the customer-facing simplicity right requires a surprising amount of engineering discipline behind the scenes.
The core problem
The physical world is messy and the network is worse. Devices drop offline in tunnels and remote areas. Pings arrive out of order, sometimes minutes late. A parcel can be scanned "delivered" at a handheld before its last GPS point ever reaches the server. If you render these events naively — last write wins, straight to the UI — the timeline flickers, jumps backwards, and customers stop trusting it.
And once customers stop trusting the tracking page, they do the most expensive thing possible: they call support.
Events, not columns
The single most important decision we made was to treat every shipment as an ordered event log, not a row of columns to overwrite. Each thing that happens — a scan, a GPS ping, a status change — is an immutable event appended to the shipment's history.
This has profound consequences. Late-arriving data is merged by its own timestamp rather than its arrival order, so a ping that shows up five minutes late still slots into the right place in history. Nothing is destroyed, so we can always reconstruct exactly what we knew and when. And debugging becomes tractable, because the event log is the truth.
Validating transitions
Not every status can follow every other status. A shipment can't go from "delivered" back to "in transit" under normal circumstances. So each status transition is validated against a state machine of what's allowed next.
- Legal transitions are applied and reflected immediately
- Illegal or suspicious ones are quarantined for review rather than shown to customers
- Out-of-order events are reordered by timestamp before the state machine sees them
This is what stops the timeline from flickering. The customer sees a monotonic, sensible progression even when the underlying data is chaotic.
Predicting the ETA
A status is history; an ETA is a promise. Predicting arrival time well means blending several signals: the shipment's current position and speed, historical transit times on that lane, hub processing delays, and live conditions like traffic and weather.
The hard part isn't the model — it's honesty. An ETA that's confidently wrong is worse than a range that's honestly uncertain. We'd rather show a tightening window that we can keep than a precise minute we'll miss. Trust, once lost on the tracking page, is very hard to win back.
Scaling the firehose
A large operation generates enormous volumes of location and event data. Writing all of it synchronously into a primary database would melt under load. Instead, ingestion is decoupled from serving: events land on a durable queue, workers process and reconcile them, and read-optimised projections serve the customer-facing page.
This separation lets each side scale independently. Ingestion can absorb a spike of pings without slowing the tracking page, and the tracking page can serve millions of views without touching the write path.
Designing for failure
At scale, something is always broken somewhere. Designing for that reality — rather than pretending it away — is what separates systems that stay honest from ones that quietly lie. Idempotent processing means a replayed event does no harm. Backpressure keeps a flood from becoming an outage. And clear degradation — showing "last known location" honestly rather than a stale dot pretending to be live — keeps trust intact when data is delayed.
Testing the untestable
The hardest part of a tracking system is that its worst failures happen in conditions you can't easily reproduce: a device that goes offline mid-journey, a burst of pings arriving in the wrong order, a scan that races ahead of its GPS point. You can't wait for those to occur in production and hope you handled them. You have to manufacture them deliberately.
Because every shipment is an event log, testing becomes tractable in a way it isn't for systems built on overwritten columns. We can capture a real, messy sequence of events from production and replay it against the system as many times as we like, tweaking timing and order to probe the edges. A late ping, a duplicated scan, an out-of-sequence status — each becomes a repeatable test rather than a once-seen mystery.
We also run the ingestion path under deliberate stress: floods of events, injected delays, simulated device dropouts. The goal isn't to prove the system works when everything's fine — that's easy — but to watch how it degrades when things aren't. Does it stay honest, showing "last known location" rather than a stale dot pretending to be live? Does it recover cleanly when a lagging source catches up? Does a replayed event do no harm?
This discipline is why the customer-facing simplicity holds. The moving dot and the honest ETA look effortless precisely because an enormous amount of deliberately nasty testing happened behind them. A tracking system that has only ever been tested on the happy path is a tracking system that will surprise you — and its customers — the first time reality misbehaves.
The takeaway
Live tracking earns trust one honest update at a time and loses it in a single flicker. The architecture that keeps it honest — event logs, validated transitions, careful ETAs, and a healthy respect for failure — is invisible when it works. Which is exactly the point.