Skip to content

// Industry

Freight telemetry that survives a bad link

A driver's phone reports position over the least reliable connection in the system. What reaches the dispatcher is not what happened — it is what arrived, in the order it arrived.

// The problem

Why this is hard

Every tracking system is a distributed system with the least reliable link in the most important place: a phone in a moving vehicle. That link drops, buffers, and comes back all at once — and almost none of the resulting failures look like failures. The map keeps drawing. The dashboard stays green. The position it shows is simply no longer true, and nothing in the system is shaped to say so. The interesting part is that none of this is a bug in the buffering, because there usually is no buffering: it starts in a wire contract that has nowhere to put a capture time, and it ends with a dispatcher acting on a truck that left forty minutes ago.

  • The payload cannot say when

    A position endpoint that accepts coordinates and nothing else forces the server to stamp arrival time. A buffered client replaying an hour of driving sends it as a burst of now — and the oldest fix, arriving last, wins.

  • Status is not freshness

    The guard on the marker is usually written on the order's lifecycle rather than on elapsed time. The two agree until the device goes quiet while the order stays open — which is the one case the guard exists for.

  • The table nobody indexed

    A location history table takes a row per ping and is read by nothing for the first year, so the missing index is never a slow query. The first person to feel it is whoever builds the feature the data was collected for.

// What matters here

The capabilities that move the needle

// Deep dives

Going deeper for logistics

// Proof

Measured on our own hardware

of replays leave the wrong fix

99%

A buffered client replaying its positions; 500 trials per arm on our own harness; 0% once the write is guarded on capture time. It reproduces with zero emulated latency — the mechanism is the client's dispatch queue, not the network.

for one order's history, unindexed

115 ms

A sequential scan at ten million rows, against 0.04 ms with the index. The history table is the fastest-growing object in a tracking system and the last one anybody indexes, because for the first year nothing reads it — by the time somebody does, the cost is already accrued at whatever size the table reached.

median reconnect wait, 10k fleet

10.5 s

One deploy puts every driver back through authorisation at once. This is what that costs the fleet, on our own harness, with the reconnection defaults nobody changed because they look configured.

Not a client outcome and not a vendor figure — numbers we took, on hardware we can name, with the method published in full. The write-ups: The timestamp that was never on the wire, You are storing the track and you cannot draw it, The deploy that logs every driver back in at once.

// From the field

What we wrote about it

// FAQ

Common questions

Yes, and the update interval is not what decides it. What decides it is whether anything in the payload says when the fix was taken. If the server stamps arrival time, then a device that lost signal and came back sends an hour of driving as a burst of now, and the map cannot tell that burst from a vehicle that has been reporting all along. The interval only bounds the error while the link is healthy — which is the case nobody needed help with.

It usually means the failure is shaped wrong for the instruments. A websocket reconnect storm produces no 5xx and no elevated request latency, because it produces no requests; a stale marker is a successful render of a wrong number; a missing index on a table nobody reads yet is never a slow query. Every failure in this sector is invisible to a request-shaped dashboard, which is why they survive so long.

Rarely. The wire contract change is small — a nullable column, a schema field, a client sending a value it already has. What costs is the reconciliation you then have to design: which clock wins when they disagree, what tolerance counts as drift rather than staleness, and what the map shows while it is unsure. That is a day of decisions rather than a week of code, and it is much cheaper before the history table is full of rows that cannot be reinterpreted.

Harnesses we built and committed, each with its output and its method in the open, and each named by the article that publishes it. Nothing here is a client's production figure — no fleet size, no incident, no recovery time. Where a claim is read from code rather than measured, the article says so in its own words rather than in a disclaimer.

// Related

Related industries

All industries

// Let's build

Building AI for logistics?

Tell us where you are. We reply within a day with a concrete next step.