Live telemetry for a commercial vehicle fleet

The challenge

Customers needed to know where their vehicles were, how they were being driven and what they were costing — continuously, not in a report the following morning.

The raw material was a constant stream of readings from devices fitted to vehicles. On its own that stream is noise. The product was everything that turns it into something an operations manager can act on inside a few seconds.

The context

Telemetry does not arrive politely. Devices lose signal in tunnels and rural areas and then deliver a backlog at once. Readings arrive late, out of order, or duplicated. Some are simply wrong.

The volume also grows with every vehicle added, and customers judge the product on whether the map is current — so ingestion could not be allowed to fall behind under load.

The approach

I treated ingestion and presentation as separate problems with separate constraints. Ingestion has to absorb bursts without dropping anything; presentation has to answer quickly regardless of what ingestion is doing.

Decoupling the two meant a backlog after a signal outage became a processing delay rather than an outage of the product itself.

The solution

Device readings are ingested continuously, validated, de-duplicated and ordered before anything downstream sees them, then written into a model built for the queries the product actually makes — current position, route history over a window, and aggregates over time.

On top of that sit live maps, historical route playback, geofencing with entry and exit alerts, fuel monitoring, maintenance tracking, and reporting with visualisations of mileage, average speed and top speed. Alerting runs through push notifications so an event reaches a phone rather than waiting to be noticed in a dashboard.

The same platform is delivered as a web portal and as native applications on Android and iOS. A documented public API was added so customers could pull their own data into their own systems — which turned the platform from a product into something other businesses could build on.

AI & automation

None, and that was correct for this system.

Everything here is deterministic: geofence entry, threshold breach, tamper detection, aggregate calculation. These are rules with exact answers, and customers were making operational decisions from them. A probabilistic component would have added cost and uncertainty to work that had neither.

What it did build was the foundation such work needs. A clean, well-modelled stream of historical operational data is the prerequisite for anything predictive later — and most organisations that want that later do not have it.

Engineering

Ordering and idempotency dominated. A reading that arrives twice must not become two events, and a batch that arrives late must land in the right place in the timeline rather than at the end of it.

Query patterns drove the storage design: showing one vehicle's current position, replaying a route over a date range and aggregating a month of driving are three different access patterns, and a schema tuned only for writes serves none of them well.

On mobile, the constraints were battery, data and intermittent connectivity — which meant careful decisions about polling, caching, and what the app should show when it cannot reach the server. Third-party SDKs were integrated for delivery and monitoring, and the architecture was designed for growth in fleet size from the outset rather than reworked when it arrived.

Outcome

Business customers could see and act on their fleets in real time from a browser or a phone, and pull the underlying data into their own systems through the API.

The platform ran and grew as a commercial product over several years, which is the outcome that matters for a system of this kind: it kept working as the thing it monitored got bigger.