EzyHaul Fleet Management Platform

EzyHaul Fleet Management Platform overview

EzyHaul runs a cross-border trucking network, and its tracking stack had stopped keeping up with the size of the fleet. Next Olive was engaged to design, build and deploy a replacement: an administrative web application for fleet operators and Logistics planners, a cross-platform driver tracking app, and the event-driven telemetry platform underneath both. The system coordinates truck tracking across borders, active driver scheduling and live route optimisation, and has to ingest a constant stream of GPS coordinates from thousands of vehicles at once.

The scope covered the full engineering lifecycle, from a baseline audit of the existing communication protocols through to the provisioning of the cloud environments. We ran the work in five phases: multi-region cloud networks and VPCs provisioned from Terraform; the Kafka and Redis ingestion pipeline; the decoupled backend microservices, geospatial computation modules and database schemas; the React Native driver app and the React web dashboard with live WebSocket interfaces; and finally container security monitoring, centralised log routing and end-to-end failover testing. Two acceptance criteria shaped every design decision: the streaming pipeline must not lose a single geospatial update even if a compute node fails, and the fleet map must reflect a location change within half a second of the packet reaching the load balancers.

Challenge in Logistics operations

The inherited platform had no central event broker. The web interface discovered vehicle movements by repeatedly polling the main database tables, and as the fleet grew that polling produced heavy lock contention on the indexes, stalled write operations and dropped connection packets from the driver apps. Data lived in disconnected storage areas and moved through batch updates, so a vehicle coordination change could take several minutes to appear, which in turn caused frequent errors in route scheduling.

The mobile side had its own failures. Along remote transit paths with patchy cellular coverage the app simply lost data whenever it went offline, and there was no recovery path. It also transmitted raw, uncompressed text blocks of coordinates at erratic intervals, which drained device batteries and ran up network costs. Fixing this meant moving off monolithic database dependencies altogether and introducing an offline-first mobile architecture fed into an event-driven message queuing pipeline.

Solution architecture & delivery

Every request from the driver app or the web dashboard enters through an elastic API gateway (AWS API Gateway fronted by NGINX) that checks the authentication token, terminates TLS and applies token-bucket rate limits tuned per client profile. Telemetry is routed straight into Apache Kafka; everything else goes to the application workloads. That split means a surge of location updates cannot starve administrative tasks such as driver registration or compliance reporting. The workloads run as isolated containers on Kubernetes and are split into a tracking ingest worker, an asset management worker, a routing optimisation planner and a notifications worker, each deployable on its own.

The ingest worker keeps lightweight persistent sockets open to devices on unstable networks. For each packet it extracts the vehicle identifier, coordinates, velocity and timestamp, validates the payload against a strict schema and drops malformed entries before they reach downstream consumers. Valid packets land in Kafka topics partitioned by vehicle identifier, which guarantees that one truck's updates are processed in the order they were sent. Geospatial consumers read the topics to detect geofence crossings, while the latest coordinate for every vehicle is written to a Redis cluster so the dashboard can fetch positions without hitting disk. Persistent records, schedules and spatial data live in PostgreSQL with PostGIS, whose spatial indexes keep boundary checks off the main tracking table.

Driver management is its own microservice governed by a lifecycle state machine: Off-Duty, Pre-Trip Inspection, Active Driving, Mandatory Rest and Post-Trip Review. Status changes from the app are validated against compliance boundaries before they are committed, active driving periods are logged for audits, and schedules that breach regional safety regulations are flagged automatically. Performance signals such as sudden braking and prolonged idling arrive through the telemetry pipeline and are attached to the driver profile. The routing planner combines an open-source routing engine with custom logic: when a planner assigns a delivery run, it computes the path from vehicle weight capacity, roadway restrictions and live transit bottlenecks, stores the route as a vector geometry, and raises deviation alerts if the truck leaves it. The same telemetry feeds fuel-efficiency reports built from speed, RPM and stop-duration trends, and a predictive maintenance rules engine that opens a service ticket when mileage, engine runtime or a diagnostic trouble code approaches a configured threshold.

The React Native driver app contains a synchronisation worker with an encrypted local SQLite store, so trucks keep recording positions through dead zones and upload compressed batches once a connection is stable; the gateway validates the batch timeline and feeds it into the same pipeline. The React and Redux Toolkit dashboard receives position and status events over WebSockets rather than polling. Access is governed by Okta with OAuth 2.0 and OpenID Connect: multi-factor login, short-lived signed JWTs, and scopes that let a driver write to their own tracking endpoint and read their own schedule while a regional planner can create routes but not touch global security settings. The estate runs active-active across multiple availability zones, autoscales on CPU and queue depth, replicates synchronously to a hot standby database in a separate region, exports encrypted backups hourly to write-once object storage, and is monitored through Prometheus, Grafana and OpenTelemetry tracing with CrowdStrike Falcon on every host.

Key features of the EzyHaul Fleet Management Platform

• Real-time telemetry ingestion over lightweight persistent sockets, with Kafka topics partitioned by vehicle ID and Redis holding the latest position of every truck
• Live fleet map in the React web dashboard fed over WebSockets, with no database polling
• Geofence evaluation by dedicated stream consumers backed by PostGIS spatial indexing
• Driver management state machine (Off-Duty, Pre-Trip Inspection, Active Driving, Mandatory Rest, Post-Trip Review) with hours-of-service logging and document verification
• Route planning from vehicle weight, roadway restrictions and live traffic, with routes stored as vector geometries for deviation alerts
• Fuel-efficiency reporting derived from engine speed, RPM and stop-duration data per transit path
• Predictive maintenance rules engine that raises service tickets from mileage, engine runtime and diagnostic trouble codes
• Offline-first React Native driver app with an encrypted SQLite store and compressed batch sync, plus Okta-issued role scopes and per-profile API rate limiting

Who this web application is for

This architecture suits Logistics operators and haulage companies whose fleets have outgrown polling-based tracking: cross-border trucking, regional distribution and any operation with thousands of vehicles streaming GPS data through areas of poor coverage. It is equally relevant to businesses that need driver compliance, maintenance scheduling and route planning in the same system of record as live tracking, and that require the platform to survive a zone or database failure without losing telemetry.

Impact & results

• Database polling for vehicle updates replaced by an event-driven pipeline, removing the index lock contention that stalled writes and dropped driver connections
• Fleet map designed to show a location change within half a second of the packet hitting the load balancers, instead of minutes via batch updates
• Telemetry from trucks in dead zones preserved in the encrypted on-device store and replayed on reconnection, so tracking histories have no gaps
• Erratic uncompressed uploads replaced with schema-validated compressed batches, addressing the battery drain and network cost of the old client
• Vehicle-keyed Kafka partitions guarantee chronological processing of each truck's packets, eliminating out-of-order tracking and geofence errors
• Individual microservices can be updated independently without taking the platform down
• Zero data loss on primary database failure: every write is committed to a hot standby in a separate region before it is acknowledged, with hourly encrypted backups
• Maintenance tickets raised automatically before assets reach usage thresholds, reducing unexpected roadside breakdowns

FAQ about the EzyHaul Fleet Management Platform