Real-Time Fleet Operations Platform — 24,000 Vehicles, Sub-Second Event Pipeline

Context

Our client operates one of the UK's largest commercial fleet networks — 24,000 vehicles across 180 depots, spanning HGVs, vans, and specialist vehicles. Their existing telematics system was built in 2017: a GPS polling architecture where each vehicle sent a position ping every 30 seconds, stored in a single MySQL 5.7 instance.

By 2024, that architecture was generating 2.9M rows per day, query times on the ops dashboard had degraded to 12–40 seconds, and the system was completely blind to driving behaviour events (harsh braking, speeding, idling) because the 30-second poll cadence missed them.

The business case was straightforward: 10% fuel efficiency improvement = £4.2M annual saving at their fleet scale. Driving behaviour data was the key input they didn't have.

Event Architecture

We moved from a polling model to an event-driven telemetry pipeline:

Device Layer

Each vehicle runs a Teltonika FMB920 telematics unit configured for 1-second position reporting and real-time event reporting (harsh braking, acceleration, idling, speeding). Events are transmitted over 4G LTE with GPRS fallback.

Ingestion Layer

A fleet of 8 Go-based ingestor services on ECS Fargate accept raw AVL data packets from the telematics units, validate checksums, decode the binary protocol, and publish structured events to Apache Kafka on MSK.

Daily throughput: ~6 million events across 6 Kafka topics:

• telemetry.position — GPS pings (1/second per vehicle)
• telemetry.events — driving behaviour events
• telemetry.fuel — fuel card transaction events from Allstar Business Solutions integration
• telemetry.maintenance — workshop system webhook events
• ops.alerts — generated alerts for dispatchers
• ops.routes — planned vs. actual route deviations

Processing Layer

Apache Flink on EMR processes the Kafka streams:

• Position aggregation — 1-second pings are aggregated to 10-second summaries for storage (reduces volume 6×)
• Behaviour scoring — rolling 30-minute window computes driver safety scores from harsh events
• Geofence matching — real-time polygon containment checks against 4,200 depot and customer site geofences
• Route deviation detection — compares actual path to planned route, triggers alerts at >400m deviation

Storage Layer

• TimescaleDB (PostgreSQL extension) for time-series position data — hypertable partitioning by week, automatic compression after 30 days
• Redis for real-time vehicle state (current position, speed, driver, active route) — 24,000 keys, each updated in <2 seconds
• S3 + Parquet for historical data beyond 90 days, queried via Athena

Presentation Layer

The dispatcher dashboard is a React + WebSocket app — vehicle positions update in the UI within 3 seconds of the device transmitting. We use Server-Sent Events (SSE) rather than WebSocket for the map feed to avoid connection overhead from 24,000 concurrent feeds.

Predictive Routing

Beyond real-time tracking, we built a route optimisation engine using Google OR-Tools. It ingests:

• Planned delivery schedules from the client's TMS
• Real-time traffic (Google Maps Platform)
• Historical journey time data from our TimescaleDB (3 years of actual journey durations by route segment, time-of-day)

The engine re-optimises routes every 15 minutes and suggests adjustments to dispatchers when it identifies a time saving of >8 minutes. Drivers receive updated ETAs via the mobile app.

Results

−18% fuel spend across the fleet in the 12 months post-launch — £3.8M annual saving. The driving behaviour scoring and dispatcher visibility of idling time drove significant behavioural change.

< 800ms end-to-end event latency (P95) — from device transmission to the dispatcher UI.

6M events/day processed with no data loss since launch (11 months).

12-second → 280ms dashboard query latency — TimescaleDB's hypertable indexing vs. the old MySQL full-table scans.

99.95% platform uptime — multi-AZ MSK and Flink on EMR with auto-recovery.