Case study · Edge-to-cloud IoT telematics
A production IoT platform for commercial fleets that pairs in-vehicle edge vision with a cloud event backbone - verifying the driver biometrically at ignition, isolating collision footage automatically, and streaming a cabin camera on demand without leaving a video link open.
Every figure below is a build fact verified by the engineering team - we do not publish invented performance percentages for this engagement.
How every event becomes evidence
As builtVerified
0
Architecture tiers, edge device to identity provider
0
Core microservices on the event backbone
0
Storage tiers behind every evidence clip
0%
Telemetry or video loss under erratic 4G/5G
A commercial fleet technology operator running connected vehicles across long-haul, last-mile and passenger transport. Identity withheld at their request.
Telematics answered where the vehicle is and nothing about who was driving, how, or what happened - and the footage was gone before anyone asked.
An edge-to-cloud platform: on-device ADAS/DMS inference, biometric driver verification, automatic evidence capture, and video on demand.
Every incident now produces a clip, a position, a timestamp and a verified driver - the four things an insurer actually asks for.
01 The client
Their existing telematics answered one question well - where is the vehicle - and left the expensive ones to phone calls and paperwork.
Every incident asks the same thing twice: what happened, and who was at the wheel when it did? Legacy telematics can answer neither from the record it keeps - which is why the answer had to be produced at the edge, in the moment, and shipped somewhere durable before the vehicle reached the next cell tower.
02 The challenge
Six problems, each cheap to describe and expensive to solve, all of them sitting between a moving vehicle on a patchy cellular link and a record somebody has to stand behind.
A vehicle can be tracked perfectly while being operated by someone who was never authorised to touch it. Sub-contracting, key sharing and shift swaps are invisible to GPS.
Drowsiness, eyes off road, phone use and a deliberately blocked camera are the leading indicators of the incident. None of them appear in a position feed.
The footage that matters is the eight seconds around impact. On a rolling partition it is overwritten long before anybody thinks to ask for it.
Vehicles drive through tunnels, dead zones and border crossings. Any design that assumes connectivity at the moment of the incident loses exactly the events it exists to capture.
Streaming continuously from two cameras per vehicle burns cellular data at a rate no fleet will fund, and most of it is footage nobody will ever open.
Every alert wants a clip. Overlapping requests duplicate the same footage, and nothing prunes itself, so cloud spend climbs with vehicle count and never comes back down.
A fleet's real exposure is not fuel or routing - it is a liability claim it cannot answer. Every one of the six problems above ends in the same place: an incident where the operator has a timestamp and the other party has a story.
03 The mandate
Each one is a constraint on the architecture rather than a feature on a roadmap - which is why they are stated as absolutes.
The vehicle is the source of truth and the network is optional. Every event and every clip must survive a total loss of connectivity and arrive intact when the link returns.
The platform must establish who is operating the vehicle at ignition and refuse to treat an unverified face as an authorised driver.
A live channel exists only while a dispatcher is watching it. No standing tunnel, no long-lived credential, no billable stream left open by accident.
Push the judgement to the edge and the durability to the cloud. Inference, cabin warning and clip selection happen on-device so they work with no network at all; correlation, retention and access control happen in the cloud where they can be governed.
Fixed the device-to-cloud contract first - Protobuf schemas, mTLS identity and the reconnection handshake - so nothing downstream depended on a wire format still in flux.
Stood up Kafka and split the consumers into five single-responsibility services, so a traffic spike in one could not reach the others.
Built the alert-to-video routine with its storage fallbacks and the local transactional buffer, then tested it by removing the network mid-extraction.
Added biometric verification against the authorised-driver registry, geofencing, and the on-demand WebRTC tunnel with short-lived credentials and automatic teardown.
The platform detects, records and reports. It does not intervene in the vehicle - no braking, no speed limiting, no remote immobilisation. Keeping actuation out of scope is what allows the detection path to be aggressive about flagging, because a false positive costs a review rather than a stopped truck.
04 The solution
One vehicle-hour produces a stream of decisions taken on-device and a matching set of records assembled in the cloud. The split between the two columns below is the architecture.
The decision happens before the upload. The edge agent classifies the impact and marks the window it needs; nothing is shipped speculatively.
Storage failure is an expected branch, not an error. When the event partition reports a write-lock, extraction falls through to the rolling partition without blocking.
Losing the network delays the clip; it never loses it. The extraction task is queued in a local transactional buffer and retried with exponential backoff.
It ends in a durable record. The clip lands in S3, the event lands in MongoDB, and the dispatcher gets one notification rather than five.
05 Architecture
A layered microservices architecture that deliberately decouples the three kinds of traffic - devices pushing telemetry in, events fanning out to consumers, and dispatchers issuing synchronous commands back down to a vehicle.
The gateway holds thousands of long-lived sockets and must never block on business logic. Kafka absorbs the burst. The five services scale on their own load curves. A rush-hour spike in road events therefore shows up as consumer lag on one topic - not as a slow dashboard, and never as a dropped event.
IMU, GPS and the two cameras feed on-device inference. ADAS scores the road scene, DMS scores the driver. A cabin warning fires locally, with no cloud round trip.
If the event crosses the severity threshold, the agent marks a clip window and requests an atomic extraction from the dedicated event partition.
On a write-lock or sector timeout the agent switches to a non-blocking read of the circular normal partition rather than failing the capture.
With no carrier, the extraction task is written to a local transactional SQLite queue and retried with exponential backoff until the link returns.
The device re-establishes a persistent TCP/TLS session with client-certificate verification, then replays everything the buffer holds through the sync handshake.
Telemetry and event frames are published to Kafka as Protobuf, keeping the network footprint compact and the schema strict across every consumer.
Geofence, notification, data, video and profile each consume independently. One slow consumer delays its own topic and nothing else.
The clip lands in S3 behind a dedupe check, the record lands in MongoDB, and a retention policy is attached so the artefact expires on schedule rather than forever.
06 Inside the build
Connecting a camera to a cloud bucket is straightforward. The engineering that makes a fleet platform hold up under a claim lives in six deliberate choices - each one as built.
Devices hold a persistent TCP/TLS connection to the ingress layer and authenticate with client-side certificate verification - mutual TLS, not a shared password or a rotating API key. A unit that cannot present a valid certificate never reaches the broker.
Because the session is long-lived, reconnection is the interesting case rather than connection. A sync handshake runs on every reconnect, so the gateway and the device agree on what the device still owes before any new telemetry is accepted.
A per-device certificate scopes compromise to one vehicle and makes revocation a gateway operation rather than a firmware rollout. Password-based IoT authentication has neither property.
Telemetry payloads are packaged as Protocol Buffers end to end - device to gateway, gateway to Kafka, Kafka to every consumer. That buys three things at once: an ultra-compact network footprint on a metered link, high-speed serialisation on constrained edge hardware, and a strict structural schema that every service is held to.
The schema is the contract. A consumer cannot quietly start accepting a differently-shaped event, which is what keeps five independent services honest about the same event stream.
Anchoring the platform on an event stream broker means the five microservices are entirely decoupled from ingestion and from each other. A regional storm or a rush-hour peak produces a massive influx of road events - and it lands as consumer lag on a topic, not as an unresponsive UI and not as data loss.
It also makes the consumer set open-ended. Adding a sixth service is a subscription, not a change to the gateway.
Guaranteeing that footage survives means assuming the flash controller will fail at exactly the wrong moment. When an ADAS or DMS event flags a critical alert, the agent attempts an atomic extraction from the dedicated high-speed event partition. If the controller reports write-locks or sector timeouts, it falls back to a non-blocking read of the circular normal-storage rolling partition.
If connectivity is gone entirely, the extraction task itself is queued in a local transactional SQLite buffer with exponential backoff - so the loss window is bounded by the buffer, not by the cellular link.
Dedicated, high-speed, written for exactly this purpose.
The circular normal-record stream, read without waiting on the lock.
SQLite queue with exponential backoff retry. Zero telemetry or video loss under erratic 4G/5G.
Authorised dispatchers can open a real-time, low-latency stream from either the cabin or the road-facing camera. To protect cellular bandwidth the connection stays dormant until it is requested: the platform commands the device to spin up a secure, temporary cloud tunnel only on demand.
Signalling uses AWS STS to mint short-lived credentials and establish a Kinesis Video signalling channel for WebRTC playback. The moment the dispatcher closes the stream, the device teardown routine fires and the tunnel is gone.
Reference-aware deduplication. Multiple requests for overlapping event footage resolve to a single S3 asset rather than several near-identical copies, which removes a whole class of redundant cloud storage billing.
Automated data lifecycles. Configurable retention tasks systematically prune outdated telemetry logs and media against corporate policy - so compliance and cloud spend are both predictable instead of both growing.
Evidence platforms fail commercially before they fail technically. Storage that only ever grows is a platform with an expiry date - so dedupe and lifecycle policy were built in from the first upload, not retrofitted after the first invoice.
07 Authorization & gates
Biometric verification is where the platform stops being a tracker and starts being a control. It runs at ignition, before the trip record exists.
Edge-to-cloud matching. On ignition the cabin DMS camera captures a face vector and streams it securely to the cloud, where similarity algorithms run it against the authorised driver registry held by the profile service.
Dynamic access control. If an unauthorised driver attempts to operate the vehicle, an alert is published across the broker immediately. If the face is unrecognised rather than rejected, the platform commands the edge device to upload a high-resolution photo for manual administrative review by dispatch.
Geofencing, blended in. Boundary calculations run alongside verification, so the platform can assert both halves of the compliance question at once: the right person, inside the approved area.
| Gate | Trigger | Outcome | Why it exists |
|---|---|---|---|
| Device identity | Client certificate absent or invalid at ingress | Connection refused; nothing enters the broker | An unverified unit must not be able to write to the fleet record |
| Driver mismatch | Face vector matches no authorised driver | Alert published; high-res still uploaded for review | Unrecognised is a question for a human, not a verdict |
| Unauthorised operation | Verified face is not authorised for this vehicle | Immediate alert across the broker to dispatch | Key sharing and sub-contracting are invisible to GPS |
| Geofence breach | Vehicle leaves an approved boundary | Breach event; dispatcher notified with position | Route adherence is the control for high-risk cargo |
| Camera obstruction | DMS reports the cabin lens blocked or covered | Cabin warning at the edge; event recorded | A blinded camera would otherwise read as a clean shift |
| Evidence extraction failure | Both storage partitions unreadable | Task retained in the local buffer and retried | A capture is never silently dropped |
The distinction between unrecognised and unauthorised is deliberate. A platform that collapses the two either locks out legitimate relief drivers or waves through people it never identified. Routing the ambiguous case to a person with a photograph attached is the only version of this that a fleet will actually keep switched on.
08 Infrastructure
Cloud-native, event-driven microservices with fault tolerance, retry and resilient processing pipelines - so the platform stays up through the conditions that produce its most valuable data.
Holds: alerts, trips, geofence definitions, driver scorecards and the biometric registry metadata.
Why: event and trip documents vary in shape by device generation and event type - a flexible document model absorbs that without a migration per firmware release.
Holds: event clips, VOD uploads, ignition stills and thumbnails.
Why: cheap, durable object storage that reference-aware dedupe and lifecycle policy can both act on, so evidence is retained deliberately rather than indefinitely.
Holds: gateway session state for persistent device connections and hot lookups on the command path.
Why: a dispatcher command has to find the right open socket in milliseconds; that lookup does not belong in the primary datastore.
Holds: the WebRTC signalling channel, STS short-lived credentials, and operator identity.
Why: the live-video path needs credentials that expire on their own, so a leaked token cannot become a standing window into a cab.
Ingress, event transport, business logic, structured state, media and identity each scale and fail on their own. That is what makes the platform's high-availability claim testable rather than aspirational: you can take one tier away and name exactly what degrades.
09 Outcomes
The figures below are as-delivered build facts, verified by the engineering team. We deliberately do not publish performance percentages for an anonymised engagement - so the impact is described as what changed in the work, not as an invented number.
0
Architecture tiers, edge device to identity provider
0
Core microservices, each independently deployable
0
Storage tiers behind every evidence clip
0
Automated gates that can halt or escalate a trip
0
Camera feeds per vehicle, streamable on demand
| Before — GPS-era telematics | After — the delivered platform |
|---|---|
| Driver identity taken on trust from the roster | Driver verified biometrically against the authorised registry at ignition |
| Risky behaviour surfaced days later, if at all | Drowsiness, distraction, phone use and camera blockage flagged in-cab as they happen |
| Collision footage lost to the rolling buffer | Impact clips isolated automatically and uploaded to durable storage |
| Events dropped whenever the vehicle lost signal | Buffered in a local transactional queue and replayed on reconnect |
| Live video either always on and unaffordable, or unavailable | On-demand WebRTC tunnel with short-lived credentials and automatic teardown |
| Insurance disputes settled on recollection and paperwork | Disputes settled with the clip, the position and the verified driver |
| Cloud storage growing with every alert, forever | Reference-aware dedupe plus policy-driven retention |
The warning now fires in the cab, at the moment of the behaviour, rather than arriving as a line in next week's report. Coaching has something specific to point at.
An incident produces a clip, a position, a timestamp and a verified driver identity - the four things an insurer or an investigator actually asks for.
Dormant video links, deduplicated media and automated retention mean the platform's running cost tracks fleet size rather than compounding with it.
10 What's next
The modular microservices boundary and the containerised over-the-air update layer were designed for the same reason: the useful thing to change over a platform's life is the model, not the hardware.
An edge tier that decides locally, a certificate-bound ingress, a broker that absorbs bursts, and a storage strategy that both deduplicates and expires - that shape transfers to any estate of connected assets that has to produce a defensible record from an unreliable link.
Application: absolute route adherence and driver-alertness verification.
Value: geofencing alerts fire the moment a high-risk vehicle deviates from its approved lane, and live DMS streaming lets dispatchers confirm alertness during long-haul night transits.
Application: high-density urban route monitoring and driver safety coaching.
Value: localised infractions such as phone use and distracted driving feed straight into safety scorecards, so managers can optimise routes and curb high-risk behaviour with evidence.
Application: driver compliance and rapid insurance turnaround.
Value: biometric validation prevents unverified or sub-contracted operators taking the wheel, and automated uploads provide the proof that settles a dispute quickly.
We design and ship production-grade IoT and agentic platforms for high-stakes operations - edge decisions that work offline, cloud records that hold up under scrutiny.