Most of your real-time logistics features are not real-time

Every logistics platform sells real-time. Real-time tracking. Real-time visibility. Real-time alerts. In the demo, a truck icon glides smoothly across a map and the engineer in the room nods approvingly.

In production, the truck icon updates every thirty seconds, and the position it shows is from forty seconds ago. The route it draws is interpolated. The "delivered" event arrives, on a normal day, between two and fifteen minutes after the actual delivery. None of this is wrong. All of it is "real-time" in the sense the industry uses the word. But the customer thinks real-time means the same thing it means in a video call, and the gap between those two definitions causes about half the customer escalations in this space.

What real-time costs

Real-time, in the strict sense, costs money. Specifically, it costs three things that all scale linearly with how strict you make the definition.

Telematics bandwidth. A truck reporting its GPS position once per second uses about sixty times more data than one reporting every minute. Multiplied by a fleet of ten thousand vehicles, by data plan costs, by the cellular dead zones where the buffered data eventually has to be sent in bursts when coverage returns. The bandwidth bill is real and the ROI on a five-second interval over a thirty-second one is, in almost every business case, nothing.

Infrastructure to handle the firehose. Once positions arrive at one-second resolution, every downstream system needs to handle that throughput. Storage. Stream processors. Geofencing engines. Push notifications to driver apps. Each of these has its own scaling profile, and they do not all scale linearly. A one-second update interval can easily mean ten times the infrastructure cost of a thirty-second one — for almost no operational improvement.

Engineering hours forever. The strictness becomes a property of the architecture, and the architecture becomes a property of the company. Every new feature has to honor it. Every new vendor integration has to honor it. The total cost is not the build; it is the next five years of every engineer thinking about latency that the business never actually needed.

What customers actually need

The interesting thing is that almost no logistics customer actually needs second-by-second positions. What they need is one of three specific things.

An accurate ETA. "When will my truck arrive?" Answering this well needs route distance, traffic, the driver's historical pace, and a position fresh enough to be the starting point. A thirty-second-old position is plenty for this. A one-second-old position does not give you a better ETA.

Geofence events. "Tell me when my truck enters the depot." This needs guaranteed event delivery (the harder problem), not faster polling. A correct event arriving forty seconds late is more valuable than a stream that might or might not have caught it.

Exception alerting. "Tell me when something is going wrong." Late departure, off-route deviation, unexpected stop. These are pattern detections over a window. They do not need real-time; they need correctness.

In all three cases, the architecture that wins is event-driven with relatively coarse polling underneath it, not high-frequency streaming. The exception is genuine live mapping — a customer literally watching a truck move on a screen, in real-time, for entertainment or supervisory purposes. That use case exists, and it is one or two screens in the business, not the whole platform.

What to actually do

The pattern that works, in our experience:

Define a data freshness contract per feature. ETA: position must be no older than ninety seconds. Geofence events: must be guaranteed delivered within five minutes of occurrence. Live map: best-effort thirty seconds, no SLA. Write these down. Show them to customers. Customers find them reassuring, not disappointing — they have been burned by vague "real-time" promises and they appreciate honesty.

Build the event spine first, then the polling. Geofence-entered, route-deviated, delivery-completed. These are the events the business runs on. Build them as durable, ordered, exactly-once events. Then layer position polling on top, at whatever frequency the freshness contract requires.

Design for the network being terrible. Drivers go through tunnels. Warehouses are inside steel buildings. The truck's modem reboots. The phone runs out of battery. A logistics system that pretends connectivity is reliable is a system that produces incorrect data on most days. Buffer locally, reconcile on reconnect, design every event to be replayable.

The honest pitch

We have built a lot of this. The version that ships and stays shipped is almost never the one with the most aggressive real-time numbers. It is the one where the contract between the system and the customer is honest about what "real-time" means, and the architecture optimizes for the things the business actually needs — accurate ETAs, guaranteed events, and resilience to a network that is occasionally trying to ruin your day.