Real-Time IoT Fleet Tracking Platform

The situation

Fleet operators usually start with whatever portal ships with their telematics hardware. It shows dots on a map, but it refreshes slowly, cannot be combined with the company’s own order and routing data, and makes it hard to add a second hardware vendor. Alerts come as daily reports. Drivers and dispatchers coordinate by phone, and proof of delivery is a signature on paper that gets scanned days later.

Teams in this situation want to own their fleet data and build workflows around it, without writing low-level device firmware or managing a fragile ingestion stack.

Our approach

1. Normalize devices at the edge of the platform

We define one canonical telemetry schema: position, speed, heading, ignition, odometer, fuel and diagnostic codes, with device and vehicle IDs. Each hardware vendor gets a small adapter that maps its payload to that schema. Devices publish over MQTT with TLS and per-device credentials, and the broker handles intermittent connections, retained messages and buffered backlogs when a truck leaves coverage and reconnects.

2. Decouple ingestion from processing

The MQTT broker forwards messages to Kafka, partitioned by vehicle so events for one vehicle stay in order. This separates thousands of long-lived device connections from the services that process the data. If a downstream service is slow or being redeployed, messages wait in Kafka instead of being dropped, and we can replay history to rebuild derived data after a bug fix.

3. Process streams, store time series

Apache Flink jobs clean and enrich telemetry: they discard impossible GPS jumps, snap positions to trips, compute idling and harsh-braking events and attach order context. Positions and trip history land in TimescaleDB, which handles large volumes of time-stamped rows with compression and retention policies, while PostGIS stores depots, customer sites and restricted zones.

4. Evaluate geofences and rules in real time

The geofence engine checks each position against the relevant zones and emits entry, exit and dwell events. Business rules, such as “notify the customer when the truck is 15 minutes away” or “alert a supervisor after 10 minutes of idling”, are configured per customer or per depot rather than hard-coded. Alerts go out through push notifications, SMS or email, with deduplication so a vehicle parked on a zone boundary does not trigger a flood.

5. Give dispatchers and drivers the same live view

A realtime API pushes position and status updates to the dispatcher dashboard over WebSockets. The React dashboard uses Mapbox GL JS with clustering and vector tiles so it stays responsive with a large fleet on screen, and adds trip replay, job assignment and exception queues. The React Native driver app receives jobs, shows navigation handoff, captures photos, signatures and barcodes as proof of delivery, and queues actions offline until connectivity returns.

How we deliver it

We start with a hardware and data review: which devices are in the field, what they report and how often, and which workflows matter most to dispatch. The first release usually covers one device vendor, the live map and a small set of geofence alerts, piloted with a single depot. Additional vendors, rules and driver-app features follow in iterations.

The platform runs on Kubernetes with infrastructure as code, autoscaling on ingestion load and dashboards for broker connections, consumer lag and alert latency. We load-test with simulated devices before each expansion; see our cloud services for how we run this kind of workload. Security covers device identity and credential rotation, encrypted transport and role-based access, so a customer or depot sees only its own vehicles.

Is this relevant to you?

If your fleet data is locked in a vendor portal, you run a mix of telematics hardware, or your drivers still work from phone calls and paper, this architecture is a good fit. Explore our web and mobile app development service or talk to us about your fleet.